Die Gegenstelle hat sich beim Klonen von Git unerwartet aufgehängt

Question

Meine git Client schlägt wiederholt mit der folgenden Fehlermeldung fehl, nachdem er einige Zeit lang versucht hat, das Repository zu klonen.

Woran könnte das liegen?

Anmerkung: Ich habe meinen SSH-Schlüssel bei meinem GIT-Hosting-Anbieter registriert

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

Answer 1

Schnelle Lösung:

Bei dieser Art von Fehlern beginne ich in der Regel mit der Erhöhung des postBuffer Größe nach:

git config --global http.postBuffer 524288000

(in einigen Kommentaren wird berichtet, dass der Wert verdoppelt werden muss):

git config --global http.postBuffer 1048576000

(Für npm publish , Martin Braun Berichte in den Kommentaren Einstellung auf höchstens 50 000 000 statt der Standardeinstellung 1 000 000)

Weitere Informationen:

Von der git config Manpage , http.postBuffer ist:

Maximale Größe des Puffers in Bytes, der von intelligenten HTTP-Transporten beim POSTing von Daten an das entfernte System verwendet wird.
Bei Anfragen, die größer als diese Puffergröße sind, werden HTTP/1.1 und Transfer-Encoding: chunked wird verwendet, um zu vermeiden, dass lokal eine große Pack-Datei erstellt wird. Die Voreinstellung ist 1 MiB, was für die meisten Anfragen ausreichend ist.

Selbst bei einem Klon kann das Auswirkungen haben, und in diesem Fall ist die OP-Joe Berichte:

[klonen] funktioniert jetzt einwandfrei

---

Hinweis: Wenn auf der Serverseite etwas schiefgelaufen ist und der Server Git 2.5+ (Q2 2015) verwendet, kann die Fehlermeldung deutlicher ausfallen.
Siehe " Git-Klonen: entfernte Seite hängt sich unerwartet auf, versuchte zu ändern postBuffer aber immer noch erfolglos ".

---

Kulai ( in den Kommentaren ) weist auf die diese Atlassian Troubleshooting Git Seite , die hinzufügt:

Error code 56 zeigt an, dass ein Curl den Fehler von CURLE_RECV_ERROR was bedeutet, dass ein Problem aufgetreten ist, das den Empfang der Daten während des Klonvorgangs verhindert hat.
In der Regel wird dies durch eine Netzwerkeinstellung, eine Firewall, einen VPN-Client oder einen Virenschutz verursacht, der die Verbindung beendet, bevor alle Daten übertragen wurden.

Außerdem wird die folgende Umgebungsvariable erwähnt, die bei der Fehlersuche helfen soll.

# 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

---

Mit Git 2.25.1 (Feb. 2020) wissen Sie mehr darüber http.postBuffer "Lösung".

Siehe 7a2dc95 festlegen , Commit 1b13e90 (22 Jan 2020) von brian m. carlson ( bk2204 ) .
(Zusammengefasst von Junio C. Hamano -- gitster -- in 53a8329 festlegen , 30. Januar 2020)
( Diskussion auf der Git-Mailingliste )

docs Erwähnung, wann eine Erhöhung des http.postBuffer sinnvoll ist

Abgezeichnet von: brian m. carlson

In einer Vielzahl von Situationen haben Benutzer Probleme mit HTTP-Push.

Oft sind diese Probleme auf Antiviren-Software, Filter-Proxys oder andere Man-in-the-Middle-Situationen zurückzuführen, manchmal aber auch auf die einfache Unzuverlässigkeit des Netzwerks.

Eine häufige Lösung für HTTP-Push-Probleme, die man im Internet findet, besteht jedoch darin, http.postBuffer zu erhöhen.

Dies funktioniert in keiner der oben genannten Situationen und ist nur in einer kleinen, stark eingeschränkten Anzahl von Fällen nützlich: im Wesentlichen, wenn die Verbindung HTTP/1.1 nicht richtig unterstützt.

Dokumentieren Sie, wann die Erhöhung dieses Wertes angebracht ist und was sie tatsächlich bewirkt, und raten Sie davon ab, sie als allgemeine Lösung für Push-Probleme zu verwenden, da sie dort nicht wirksam ist.

Daher ist die Dokumentation für git config http.postBuffer umfasst jetzt:

http.postBuffer

Maximale Größe des Puffers in Bytes, der von intelligenten HTTP-Transporten beim POSTing von Daten an das entfernte System verwendet wird.
Für Anfragen, die diese Puffergröße überschreiten, wird HTTP/1.1 und Transfer-Encoding: chunked verwendet, um zu vermeiden, dass lokal eine große Paketdatei erstellt wird.
Der Standardwert ist 1 MiB, was für die meisten Anfragen ausreicht.

Beachten Sie, dass die Anhebung dieses Limits nur für die Deaktivierung der Chunked-Transfer-Kodierung wirksam ist und daher nur verwendet werden sollte, wenn der entfernte Server oder ein Proxy nur HTTP/1.0 unterstützt oder nicht mit dem HTTP-Standard übereinstimmt.
Die Erhöhung dieses Wertes ist im Allgemeinen keine effektive Lösung für die meisten Push-Probleme, sondern kann den Speicherverbrauch erheblich erhöhen, da der gesamte Puffer auch bei kleinen Pushs zugewiesen wird. .

Answer 2

Gleicher Fehler bei Bitbucket. Behoben durch

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

Answer 3

Basierend auf diese Antwort Ich habe folgendes versucht (mit https url):

1. erstes Klonen des Repos:

git clone --depth 25 url-here

2. Fetch-Commits mit zunehmender Zweimal pro Versuchstiefe:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...und so weiter

3. schließlich (wenn ich denke, dass genug geholt wurde) führe ich git fetch --unshallow - und es ist vollbracht.

Der Prozess nimmt natürlich viel mehr Zeit in Anspruch, aber in meinem Fall ist die Einstellung http.postBuffer et core.compression hat nicht geholfen.

UPD : Ich habe herausgefunden, dass das Abrufen über ssh funktioniert für jede Repo-Größe (zufällig entdeckt), durchgeführt mit git clone <ssh url> vorausgesetzt, Sie haben ssh-Schlüssel erstellt. Sobald das Repo abgerufen ist, ändere ich die Remote-Adresse mit git remote set-url <https url to repo>

Answer 4

Der http.postBuffer-Trick hat pas für mich arbeiten. Wie auch immer:

Für andere, die dieses Problem haben, könnte es ein Problem mit GnuTLS sein. Wenn Sie den Verbose-Modus einstellen, kann der zugrunde liegende Fehler in etwa so aussehen wie der folgende Code.

Leider ist meine einzige Lösung bisher die Verwendung von SSH.

Ich habe eine Lösung gesehen, die veröffentlicht wurde anderswo um Git mit OpenSSL anstelle von GnuTLS zu kompilieren. Es gibt einen aktiven Fehlerbericht für dieses Problem aquí .

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

Answer 5

Bei gemeinsam genutzter Bandbreite sollten Sie versuchen, zu klonen, wenn die Belastung geringer ist. Ansonsten versuchen Sie es mit einer Hochgeschwindigkeitsverbindung. Wenn es immer noch nicht funktioniert, verwenden Sie bitte den folgenden Befehl,

git config --global http.postBuffer 2048M
git config --global http.maxRequestBuffer 1024M
git config --global core.compression 9

git config --global ssh.postBuffer 2048M
git config --global ssh.maxRequestBuffer 1024M

git config --global pack.windowMemory 256m 
git config --global pack.packSizeLimit 256m

Und versuchen Sie erneut zu klonen. Möglicherweise müssen Sie diese Einstellungen entsprechend der verfügbaren Speichergröße ändern.