자식 복제 중에 원격 끝이 예기치 않게 끊어졌습니다. 수 있습니까?

내 git클라이언트는 반복적으로 약간의 시간에 대한 저장소를 복제하려고 후 다음과 같은 오류와 함께 실패합니다.

여기서 무엇이 문제가 될 수 있습니까?

참고 : SSH 키를 GIT 호스팅 제공 업체에 등록했습니다

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly

답변

빠른 솔루션 :

이러한 종류의 오류가 발생하면 일반적으로 다음과 같이 postBuffer크기를 늘 립니다 .

git config --global http.postBuffer 524288000

(아래의 일부 의견은 가치를 두 배로 늘려야한다고보고합니다) :

git config --global http.postBuffer 1048576000

추가 정보:

로부터 git configman 페이지 , http.postBuffer약 :

원격 시스템에 데이터를 POST 할 때 스마트 HTTP 전송에 사용되는 버퍼의 최대 크기 (바이트)입니다.
이 버퍼 크기보다 큰 요청의 경우 HTTP / 1.1 Transfer-Encoding: chunked은 대규모 팩 파일을 로컬로 작성하지 않도록하는 데 사용됩니다. 기본값은 1MiB이며 대부분의 요청에 충분합니다.

클론의 경우에도 효과가있을 수 있으며이 경우 OP Joe 는 다음과 같이보고합니다.

[복제]는 지금 잘 작동

참고 : 서버 측에서 문제가 발생하고 서버가 Git 2.5 이상 (Q2 2015)을 사용하는 경우 오류 메시지가보다 명확 할 수 있습니다.
” 깃트 클로닝 : 원격 엔드가 예기치 않게 끊어져 변경을 시도 postBuffer했지만 여전히 실패 “를 참조하십시오.

Kulai ( 의견에 의하면 )는 이 Atlassian Troubleshooting Git 페이지 를 가리키며 다음을 추가합니다.

Error code 56curl이 오류를 수신했음을 나타내며 CURLE_RECV_ERROR이는 복제 프로세스 중에 데이터를 수신하지 못하게하는 문제가 있음을 의미합니다.
일반적으로 모든 데이터가 전송되기 전에 연결을 종료하는 네트워크 설정, 방화벽, VPN 클라이언트 또는 안티 바이러스로 인해 발생합니다.

또한 디버깅 프로세스를 돕기 위해 다음 환경 변수에 대해서도 언급합니다.

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

Git 2.25.1 (2020 년 2 월)을 사용하면이 http.postBuffer“솔루션” 에 대해 더 많이 알 수 있습니다 .

brian m의 commit 7a2dc95 , commit 1b13e90 (2020 년 1 월 22 일)을 참조하십시오 . 칼슨 ( bk2204) .
(가 합병 – Junio C 하마노 gitster– 에 53a8329 커밋 2020 30 년 1 월)
( 망할 놈의 메일 링리스트의 토론을 )

docs: http.postBuffer를 늘릴 때 언급 할 가치가있다

서명자 : brian m. 칼슨

다양한 상황의 사용자는 HTTP 푸시 문제에 직면합니다.

종종 이러한 문제는 바이러스 백신 소프트웨어, 프록시 필터링 또는 기타 중간자 상황으로 인해 발생합니다. 다른 경우에는 네트워크의 단순 불안정성 때문입니다.

그러나 온라인에서 발견 된 HTTP 푸시 문제에 대한 일반적인 해결책은 http.postBuffer를 늘리는 것입니다.

이는 위에서 언급 한 상황 중 어느 것도 작동하지 않으며 매우 제한적인 소수의 경우에만 유용합니다. 본질적으로 연결이 HTTP / 1.1을 제대로 지원하지 않는 경우에 유용합니다.

이 값을 올릴 때 적절하고 실제로하는 일을 문서화하고 사람들이 푸시 문제에 대한 일반적인 해결책으로 사용하지 않도록하십시오. 효과적이지 않기 때문입니다.

따라서 현재 문서 git config http.postBuffer에는 다음이 포함됩니다.

http.postBuffer

원격 시스템에 데이터를 POST 할 때 스마트 HTTP 전송에 사용되는 버퍼의 최대 크기 (바이트)입니다.
이 버퍼 크기보다 큰 요청의 경우 HTTP / 1.1 및 Transfer-Encoding : chunked는 대규모 팩 파일을 로컬로 작성하지 않도록하기 위해 사용됩니다.
기본값은 1MiB이며 대부분의 요청에는 충분하지 않습니다.

이 제한을 높이는 것은 청크 전송 인코딩을 비활성화하는 데만 유효하므로 원격 서버 또는 프록시가 HTTP / 1.0 만 지원하거나 HTTP 표준을 준수하지 않는 경우에만 사용해야합니다.
이것을 올리는 것은 일반적으로 대부분의 푸시 문제에 대한 효과적인 솔루션은 아니지만 작은 버퍼에도 전체 버퍼가 할당되므로 메모리 소비를 크게 늘릴 수 있습니다 .

답변

Bitbucket과 동일한 오류. 에 의해 고정

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0

답변

http.postBuffer 트릭은하지 않았다 작동 . 하나:

이 문제가 발생하는 다른 사람들에게는 GnuTLS에 문제가있을 수 있습니다. 상세 모드를 설정하면 기본 오류가 아래 코드 줄에 표시되는 것을 볼 수 있습니다.

불행히도, 지금까지 유일한 해결책은 SSH를 사용하는 것입니다.

GnuTLS 대신 OpenSSL로 Git을 컴파일하기 위해 다른 곳에 게시 된 솔루션을 보았습니다 . 이 문제에 대한 활성 버그 보고서가 있습니다 .

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject:
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
<
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject:
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
<
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

답변

Obs .: 변화 http.postBuffer 또한 하려면 client_max_body_size의 값을 조정하여 gitlab이 클라이언트의 더 큰 바디 크기를 허용하도록 Nginx 구성 파일을 설정해야 할 수도 있습니다.

그러나 Gitlab 머신 또는 네트워크의 머신에 액세스 할 수 있고이를 사용하는 경우 해결 방법이 있습니다git bundle .

  1. 소스 머신의 git 저장소로 이동하십시오.
  2. 운영 git bundle create my-repo.bundle --all
  3. my-repo.bundle 파일을 대상 컴퓨터로 전송 (예 : rsync 사용)
  4. 대상 컴퓨터에서 실행 git clone my-repo.bundle
  5. git remote set-url origin "path/to/your/repo.git"
  6. git push

모두 제일 좋다!

답변

나를 위해 일한 유일한 것은 SSH 링크 대신 HTTPS 링크를 사용하여 repo를 복제하는 것입니다 .

답변

https를 사용 중이고 오류가 발생하는 경우

http 대신 https를 사용하여 문제를 해결했습니다.

git config --global https.postBuffer 524288000

답변

이 답변을 기반으로 https https를 사용하여 다음을 시도했습니다.

  1. 리포의 초기 복제 :

git clone --depth 25 url-here

  1. 시도 깊이 당 두 번 증가하는 커밋 커밋 :

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

…등등

  1. 결국 (충분히 페치되었다고 생각 될 때) 실행 git fetch --unshallow합니다.

이 과정은 분명히 훨씬 더 많은 시간이 걸리지 만 내 경우 설정에서 http.postBuffer와 core.compression도움이되지 않았다.

UPD는 : 나는 통해 가져 오는 것을 발견 ssh를하는 것은 함께 할 (우연히 발견) 어떤 REPO 크기, 작동 git clone <ssh url>이 SSH 키를 생성 한 주어진. 저장소를 가져 오면 다음을 사용하여 원격 주소를 변경합니다.git remote set-url <https url to repo>

이 글은 Git 카테고리에 분류되었고 태그가 있으며 님에 의해 에 작성되었습니다.