Das entfernte Ende legte beim Klonen von Git unerwartet auf

Mein gitClient schlägt wiederholt mit dem folgenden Fehler fehl, nachdem er einige Zeit versucht hat, das Repository zu klonen.

Was könnte hier das Problem sein?

Hinweis: Ich habe meinen SSH-Schlüssel beim GIT-Hosting-Anbieter registriert

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

Schnelle Lösung:

Bei dieser Art von Fehler beginne ich normalerweise damit, die postBufferGröße zu erhöhen um:

git config --global http.postBuffer 524288000

(Einige Kommentare unten berichten, dass der Wert verdoppelt werden muss):

git config --global http.postBuffer 1048576000

Mehr Informationen:

Auf der git configManpage geht http.postBufferes um:

Maximale Größe des Puffers in Byte des Puffers, der von intelligenten HTTP-Transporten beim POSTEN von Daten an das Remote-System verwendet wird.
Bei Anforderungen, die größer als diese Puffergröße sind, wird HTTP / 1.1 Transfer-Encoding: chunkedverwendet, um zu vermeiden, dass lokal eine massive Packdatei erstellt wird. Die Standardeinstellung ist 1 MiB, was für die meisten Anfragen ausreicht.

Selbst für den Klon kann dies Auswirkungen haben, und in diesem Fall berichtet der OP Joe :

[Klon] funktioniert jetzt einwandfrei

Hinweis: Wenn auf der Serverseite ein Fehler aufgetreten ist und der Server Git 2.5+ (Q2 2015) verwendet, ist die Fehlermeldung möglicherweise expliziter.
Siehe " Git-Klonen: Remote-Ende hat unerwartet aufgelegt, versucht zu ändern, schlägt postBufferaber immer noch fehl ".

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

Error code 56Zeigt an, dass eine Locke empfangen wurde, deren Fehler CURLE_RECV_ERRORbedeutet, dass ein Problem aufgetreten ist, das den Empfang der Daten während des Klonvorgangs verhindert hat.
Dies wird normalerweise durch eine Netzwerkeinstellung, eine Firewall, einen VPN-Client oder ein Antivirenprogramm verursacht, die die Verbindung beenden, bevor alle Daten übertragen wurden.

Außerdem wird die folgende Umgebungsvariable erwähnt, um den Debugging-Prozess zu unterstützen.

# 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 (Februar 2020) wissen Sie mehr über diese http.postBuffer"Lösung".

Siehe Commit 7a2dc95 , Commit 1b13e90 (22. Januar 2020) von Brian M. Carlson ( bk2204) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit 53a8329 , 30. Januar 2020)}
( Diskussion der Git-Mailingliste )

docs: Erwähnen Sie, wenn das Erhöhen von http.postBuffer wertvoll ist

^{Unterzeichnet von: brian m. Carlson}

Benutzer in einer Vielzahl von Situationen haben Probleme mit HTTP-Pushs.

Oft sind diese Probleme auf Antivirensoftware, das Filtern von Proxys oder andere Man-in-the-Middle-Situationen zurückzuführen. In anderen Fällen sind sie auf eine einfache Unzuverlässigkeit des Netzwerks zurückzuführen.

Eine häufige Lösung für online gefundene HTTP-Push-Probleme ist jedoch die Erhöhung von http.postBuffer.

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 ordnungsgemäß unterstützt.

Dokumentieren Sie, wann die Erhöhung dieses Werts angemessen ist und was er tatsächlich bewirkt, und halten Sie die Benutzer davon ab, ihn als allgemeine Lösung für Push-Probleme zu verwenden, da er dort nicht wirksam ist.

Die Dokumentation für den git config http.postBufferMoment enthält also:

http.postBuffer

Maximale Größe des Puffers in Byte des Puffers, der von intelligenten HTTP-Transporten beim POSTEN von Daten an das Remote-System verwendet wird.
Bei Anforderungen, die größer als diese Puffergröße sind, werden HTTP / 1.1 und Transfer-Encoding: Chunked verwendet, um zu vermeiden, dass lokal eine massive Pack-Datei erstellt wird.
Die Standardeinstellung ist 1 MiB, was für die meisten Anfragen ausreicht.

Beachten Sie, dass das Erhöhen dieses Grenzwerts nur zum Deaktivieren der Chunked-Transfer-Codierung wirksam ist und daher nur verwendet werden sollte, wenn der Remote-Server oder ein Proxy nur HTTP / 1.0 unterstützt oder nicht mit dem HTTP-Standard übereinstimmt.
Dies zu erhöhen ist im Allgemeinen keine effektive Lösung für die meisten Push-Probleme, kann jedoch den Speicherverbrauch erheblich erhöhen, da der gesamte Puffer auch für kleine Pushs zugewiesen wird .

Gleicher Fehler mit Bitbucket. Behoben von

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

Der http.postBuffer-Trick hat bei mir nicht funktioniert. Jedoch:

Für andere, bei denen dieses Problem auftritt, kann es ein Problem mit GnuTLS sein. Wenn Sie den ausführlichen Modus einstellen, wird der zugrunde liegende Fehler möglicherweise in Anlehnung an den folgenden Code angezeigt.

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

Ich habe eine Lösung gesehen, die an anderer Stelle veröffentlicht wurde , um Git mit OpenSSL anstelle von GnuTLS zu kompilieren. Es gibt einen aktiven Fehlerbericht für das Problem hier .

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

Hinweis: http.postBufferZum Ändern muss möglicherweise auch die Nginx-Konfigurationsdatei für gitlab eingerichtet werden, um größere Körpergrößen für den Client zu akzeptieren, indem der Wert von client_max_body_size angepasst wird.

Es gibt jedoch eine Problemumgehung, wenn Sie Zugriff auf den Gitlab-Computer oder einen Computer in seinem Netzwerk haben, und zwar mithilfe von git bundle.

1. Gehen Sie zu Ihrem Git-Repository auf dem Quellcomputer
2. Lauf git bundle create my-repo.bundle --all
3. Übertragen Sie (z. B. mit rsync) die Datei my-repo.bundle auf den Zielcomputer
4. Führen Sie auf dem Zielcomputer aus git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Alles Gute!

Das einzige, was für mich funktioniert hat, war, das Repo über den HTTPS- Link anstelle des SSH- Links zu klonen .

Wenn Sie https verwenden und den Fehler erhalten.

Ich habe https anstelle von http verwendet und es hat mein Problem gelöst

git config --global https.postBuffer 524288000

Basierend auf dieser Antwort habe ich Folgendes versucht (mit https-URL):

1. anfängliches Klonen von Repo:

git clone --depth 25 url-here

2. Abruf-Commits mit zweimaliger Erhöhung 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 wird) renne ich git fetch --unshallow- und es ist geschafft.

Der Prozess offensichtlich braucht viel mehr Zeit, aber in meinem Fall Einstellung http.postBufferund core.compressionhat nicht geholfen.

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

Ich habe eine Lösung erhalten, nachdem ich den folgenden Befehl verwendet habe:

git repack -a -f -d --window=250 --depth=250

Ich habe das gleiche Problem, ich habe dies mit der Trial-and-Error-Methode behoben. Ich habe den Wert für core.compression geändert, bis er funktioniert.

Ich habe nach 3 Versuchen mit "git config --global core.compression 1" begonnen

"git config --global core.compression 4" hat bei mir funktioniert.

Dies ist auf das Problem mit der Internetverbindung zurückzuführen. Ich hatte das gleiche Problem. Ich habe eine flache Kopie des Codes mit erstellt

git clone --depth 1 //FORKLOCATION

Später wurde der Klon mit geheiligt

git fetch --unshallow

in /etc/resolv.confder Zeile am Ende der Datei hinzufügen

options single-request

Nun, ich wollte eine 219-MB-Lösung pushen, hatte aber kein Glück damit

git config --global http.postBuffer 524288000

Und was bringt es überhaupt, einen Postpuffer von 525 MB zu haben? Es ist dumm. Also habe ich mir den Git-Fehler unten angesehen:

Total 993 (delta 230), reused 0 (delta 0)
POST git-receive-pack (5173245 bytes)
error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

Also will Git 5 MB posten, dann habe ich den Postpuffer auf 6 MB gesetzt und es funktioniert

git config --global http.postBuffer 6291456

Ich hatte das gleiche Problem und es hing mit einer schlechten Internetverbindung zusammen. Nach dem Versuch mit einigen Git-Konfigurationen habe ich mich gerade von meinem Netzwerk getrennt und wieder verbunden und es funktioniert!.

Es scheint, dass nach dem Verbindungsverlust (oder der Aktion, die diese Situation auslöst) Git stecken bleibt.

Ich hoffe, dass es jemandem hier mehr helfen könnte.

Beste,

Ich hatte auch das gleiche Problem. Der Grund für dieses Problem sind Kurtis 'Beschreibungen über GNUTLS.

Wenn Sie den gleichen Grund haben und Ihr System Ubuntu ist, können Sie dieses Problem lösen, indem Sie die neueste Version von git von installieren. ppa:git-core/ppaDie Befehle lauten wie folgt.

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get git

Ich hatte dieses Problem beim Klonen von Daten (über HTTP) von Remote-Git-Repo, das auf einer AWS EC2-Instanz gehostet wird, die von elastischer Beanstalk verwaltet wird. Das Klonen selbst wurde auch auf der AWS EC2-Instanz durchgeführt.

Ich habe alle oben genannten Lösungen und ihre Kombinationen ausprobiert:

• Git's einstellen http.postBuffer
• Rahmenhttp.maxrequestbuffer
• Deaktivieren Sie die Git-Komprimierung und versuchen Sie "flach" git cloneund dann git fetch --unshallow- siehe fatal: frühe EOF fatal: Index-Pack fehlgeschlagen
• Tuning der GIT-Speichereinstellungen - packedGitLimit ua, siehe hier: fatal: früh EOF fatal: Index-Pack fehlgeschlagen
• Tunning-Nginx-Konfiguration - Einstellung client_max_body_sizeauf großen Wert und 0 (unbegrenzt); Rahmenproxy_request_buffering off;
• Rahmen options single-request in /etc/resolv.conf
• Drosselung des Git-Client-Durchsatzes mit Rinnsal
• mit strace zum verfolgen git clone
• unter Berücksichtigung des Updates des Git-Clients

Nach all dem war ich immer wieder mit dem gleichen Problem konfrontiert, bis ich feststellte, dass das Problem darin besteht, dass Elastic Load Balancer (ELB) die Verbindung trennt . Nachdem ich direkt auf die EC2-Instanz (die Hosting-Git-Repo) zugegriffen habe, anstatt ELB zu durchlaufen, habe ich es endlich geschafft, Git-Repo zu klonen! Ich bin mir immer noch nicht sicher, welcher der ELB-Parameter (Timeout) dafür verantwortlich ist, daher muss ich noch einige Nachforschungen anstellen.

AKTUALISIEREN

Es scheint, dass die Änderung der Verbindungsentlastungsrichtlinie für AWS Elastic Load Balancer durch Erhöhen des Zeitlimits von 20 Sekunden auf 300 Sekunden dieses Problem für uns behoben hat.

Die Beziehung zwischen dem git clone Fehlern und dem "Verbindungsabbau" ist seltsam und für uns nicht offensichtlich. Es kann sein, dass die Änderung des Verbindungsabbruchs einige interne Änderungen in der ELB-Konfiguration verursacht hat, die das Problem mit dem vorzeitigen Schließen der Verbindung behoben haben.

Dies ist die verwandte Frage im AWS-Forum (noch keine Antwort): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Ich hatte ein ähnliches Problem, aber mit einem Bambusjob. Bamboo konnte einen lokalen Klon (lokal, aber über einen SSH-Proxy) eines zwischengespeicherten Repositorys nicht ausführen. Ich habe den Cache gelöscht und danach hat es funktioniert, aber jedes Mal, wenn versucht wird, aus dem lokalen Cache zu klonen, ist ein Fehler aufgetreten. Scheint ein Problem mit der Bambus-Version des SSH-Proxys zu sein, die nicht per se git ist.

Ich habe den gleichen Fehler bei der Verwendung von BitBucket. Ich habe https aus der URL meines Repos entfernt und die URL mit festgelegt HTTP.

git remote set-url origin http://mj@bitbucket.org/mj/pt.git

Gelöst mit WLAN-Router Einstellung:

Ich habe das gleiche Problem, wenn ich mit den Einstellungen PPPoE (automatische Anmeldung per WLAN-Router) im WLAN bin.

Git Download-Geschwindigkeit ist sehr langsam 15kb.

packet_write_wait: Verbindung zu Port 17.121.133.16 22: Pipe gebrochen: Das Remote-Ende hat unerwartet schwerwiegend aufgelegt: Frühes EOF-Fatal: Indexpaket fehlgeschlagen

Lösung: 1. Einstellung auf Dynamic IP geändert, WLAN-Router neu starten. 2. Von der Webbrowser-Anmeldung zum Internetdienstanbieter-Portal (PPPoE nicht konfigurieren, automatische Anmeldung über den WLAN-Router).

Nach dem Ändern von Git beträgt die Download-Geschwindigkeit 1,7 MB.

Dies löste mein Problem:

git clone --depth=20 https://repo.git -b master

Die obigen Tricks haben mir nicht geholfen, da das Repo größer war als die maximal zulässige Push-Größe bei Github. Was funktionierte, war eine Empfehlung von https://github.com/git-lfs/git-lfs/issues/3758, die vorschlug, jeweils ein bisschen zu pushen:

Wenn Ihre Niederlassung eine lange Geschichte hat, können Sie versuchen, eine kleinere Anzahl von Commits gleichzeitig (z. B. 2000) mit folgenden Schritten zu übertragen:

git rev-list --reverse master | ruby -ne 'i ||= 0; i += 1; puts $_ if i % 2000 == 0' | xargs -I{} git push origin +{}:refs/heads/master

Das wird durch die Geschichte des Meisters gehen und Objekte 2000 gleichzeitig schieben. (Sie können natürlich an beiden Stellen einen anderen Zweig ersetzen, wenn Sie möchten.) Wenn dies erledigt ist, sollten Sie in der Lage sein, den Master ein letztes Mal zu pushen, und die Dinge sollten auf dem neuesten Stand sein. Wenn 2000 zu viele sind und Sie das Problem erneut haben, können Sie die Zahl so anpassen, dass sie kleiner ist.

Verschwendete einige Stunden damit, einige dieser Lösungen auszuprobieren, führte dies jedoch schließlich auf ein Unternehmens-IPS (Instrusion Protection System) zurück, das die Verbindung nach der Übertragung einer bestimmten Datenmenge trennte.

Versuchen Sie für gemeinsam genutzte Bandbreite zu klonen, wenn die Last geringer ist. Versuchen Sie es andernfalls mit einer Hochgeschwindigkeitsverbindung. Wenn dies 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 Ihrer verfügbaren Speichergröße ändern.

Es kann so einfach wie ein Serverproblem sein. Wenn Sie GitHub verwenden, überprüfen Sie https://twitter.com/githubstatus . Ich habe das gerade zum ersten Mal gesehen und festgestellt, dass GitHub wackelt . Ein paar Minuten später funktionierte es wieder gut.

Dies funktionierte für mich, indem ich den Googles-Nameserver einrichtete, da kein Standard-Nameserver angegeben wurde, gefolgt vom Neustart des Netzwerks:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

Ich war mit diesem Problem bei der Verwendung von Git in Kubuntu konfrontiert. Ich habe auch eine allgemeine Instabilität im Netzwerk festgestellt und eine Lösung gefunden .

Fügen Sie in /etc/resolv.conf die Zeile am Ende der Datei hinzu

Optionen Einzelanforderung

Diese festen Verzögerungen vor jeder Auflösung von Domainnamen und Git begannen danach wie ein Zauber zu wirken.

Ich habe festgestellt, dass mein Problem mit der .netrc-Datei zusammenhängt. Wenn ja, können Sie Folgendes tun:

Öffnen Sie Ihre .netrc-Datei und bearbeiten Sie sie so, dass sie Github-Anmeldeinformationen enthält. Geben Sie nano ~/netrcoder eingedit ~/netrc

Fügen Sie dann Folgendes hinzu: * machine github.com

Login Benutzername

Passwort SECRET

Maschine api.github.com

Login Benutzername

Passwort SECRET *

Sie können dort Ihr unformatiertes Passwort angeben, aber aus Sicherheitsgründen generieren Sie hier ein Authentifizierungstoken , das Github-Token Passwort und fügen Sie es anstelle Ihres Passworts ein.

Hoffe das hilft jemandem

Dies kann an der Größe der Commits liegen, die verschoben werden. Teilen Sie die Anzahl der Commits wie folgt auf:

git log -5

Sehen Sie sich die letzten 5 Commits an und Sie würden wissen, welche nicht auf Remote übertragen werden. Wählen Sie eine Commit-ID aus und verschieben Sie alle Commits auf diese ID:

git push <remote_name> <commit_id>:<branch_name>

HINWEIS: Ich habe gerade mein Commit überprüft, das die größte Größe haben könnte. bis dahin zuerst hochgeschoben. Der Trick hat funktioniert. !!

Ich habe Git Push von meinem OS X El Capitan Mac aus gemacht. Ich habe den gleichen Fehler erhalten, ich habe alles versucht, um das zu beheben, was ich bei Google / Stackoverflow gefunden habe. In Bezug auf die Version verwende ich die neueste Version von Github, 2.7.4. Ich habe ein Projekt in meinem lokalen System erstellt und wollte, dass dies in meinem Github-Konto öffentlich ist. Die Projektgröße lag nicht bei 8 MB. Ich bemerkte, dass beim Verschieben einiger Dateien mit einer Größe von etwa 1,5 MB die Daten ordnungsgemäß übertragen wurden, bei großer Größe jedoch mit demselben Fehler fehlschlug.

Die einzige Option, die ich hatte, war, Änderungen in MB-Teilen zu pushen. Jetzt habe ich alle Änderungen vorangetrieben. Dies ist eine Problemumgehung für mich, bis ich die Lösung für diese Lösung gefunden habe.

Sie können also auch versuchen, Änderungen in mehreren Commits voranzutreiben. Wenn Sie mehrere Ordner haben, können Sie die Änderungen für jeden Ordner verschieben (wenn die Ordnergröße nicht groß ist).

Ich hoffe, dies wird Ihnen helfen, kontinuierlich an dem Projekt zu arbeiten.

Versuchen Sie angesichts des gleichen Problems, sich mit einem anderen Zweig zusammenzuschließen und ihn zu entfernen. Es funktioniert bei mir genauso.

Verwenden Sie sshstattdessen http, es ist keine gute Antwort auf diese Frage, aber zumindest funktioniert es für mich