fatal: frühe EOF fatal: Index-Pack fehlgeschlagen

Ich habe gegoogelt und viele Lösungen gefunden, aber keine funktioniert für mich.

Ich versuche, von einem Computer aus zu klonen, indem ich eine Verbindung zum Remote-Server im LAN-Netzwerk herstelle.
Das Ausführen dieses Befehls von einem anderen Computer aus führt zu Fehlern.
Aber das Ausführen des Befehls SAME clone mit git: //192.168.8.5 ... auf dem Server ist in Ordnung und erfolgreich.

Irgendwelche Ideen ?

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

Ich habe diese Konfiguration hinzugefügt, .gitconfigaber auch keine Hilfe.
Verwenden der Git-Version 1.8.5.2.msysgit.0

[core]
    compression = -1

Schalten Sie zuerst die Komprimierung aus:

git config --global core.compression 0

Als nächstes machen wir einen Teilklon, um die Menge der Informationen zu kürzen, die runterkommen:

git clone --depth 1 <repo_URI>

Wenn das funktioniert, gehen Sie in das neue Verzeichnis und rufen Sie den Rest des Klons ab:

git fetch --unshallow 

oder alternativ

git fetch --depth=2147483647

Machen Sie jetzt einen regelmäßigen Zug:

git pull --all

Ich denke, es gibt einen Fehler mit msysgit in den 1.8.x-Versionen, der diese Symptome verschlimmert. Eine andere Option ist es, es mit einer früheren Version von git zu versuchen (<= 1.8.3, glaube ich).

Dieser Fehler kann bei Speicherbedarf von git auftreten. Sie können diese Zeilen in der globalen git Konfigurationsdatei hinzufügen , die ist .gitconfigin $USER_HOME, um das Problem zu beheben.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

endlich gelöst durch git config --global core.compression 9

Aus einem BitBucket-Problem-Thread:

Ich habe es fast fünf Mal versucht, und es passiert immer noch.

Dann habe ich versucht, eine bessere Komprimierung zu verwenden und es hat funktioniert!

git config --global core.compression 9

Aus der Git-Dokumentation:

core.compression
Eine Ganzzahl -1..9, die eine Standardkomprimierungsstufe angibt. -1 ist die zlib-Standardeinstellung.
0 bedeutet keine Komprimierung und 1..9 sind verschiedene Kompromisse zwischen Geschwindigkeit und Größe, wobei 9 am langsamsten ist.
Wenn diese Option aktiviert ist, werden andere Komprimierungsvariablen wie core.looseCompression und pack.compression standardmäßig bereitgestellt.

Wie @ingyhere sagte:

Flacher Klon

Schalten Sie zuerst die Komprimierung aus:

git config --global core.compression 0

Als nächstes machen wir einen Teilklon, um die Menge der Informationen zu kürzen, die runterkommen:

git clone --depth 1 <repo_URI>

Wenn das funktioniert, gehen Sie in das neue Verzeichnis und rufen Sie den Rest des Klons ab:

git fetch --unshallow

oder alternativ

git fetch --depth=2147483647

Jetzt ziehen Sie:

git pull --all

Dann, um das Problem Ihrer lokalen Niederlassung nur Tracking-Master zu lösen

Öffnen Sie Ihre Git-Konfigurationsdatei ( .git/config) im Editor Ihrer Wahl

wo steht:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

Ändern Sie die Zeile

fetch = +refs/heads/master:refs/remotes/origin/master

zu

fetch = +refs/heads/*:refs/remotes/origin/*

Führen Sie einen Git-Abruf durch, und Git zieht jetzt alle Ihre Remote-Zweige ab

In meinem Fall war das sehr hilfreich:

git clone --depth 1 --branch $BRANCH $URL

Dadurch wird die Kaufabwicklung nur auf den genannten Zweig beschränkt, wodurch der Vorgang beschleunigt wird.

Hoffe das wird helfen.

Ich habe all diese Befehle ausprobiert und keiner funktioniert für mich, aber was funktioniert, war, die git_url in http statt ssh zu ändern

if is clone command do:

git clone <your_http_or_https_repo_url> 

Andernfalls, wenn Sie an einem vorhandenen Repo arbeiten, tun Sie dies mit

git remote set-url origin <your_http_or_https_repo_url>

hoffe das hilft jemandem!

Ich habe diesen Fehler erhalten, als git nicht mehr genügend Speicher hat.

Das Freigeben von Speicherplatz (in diesem Fall: Beenden eines Kompilierungsauftrags) und erneutes Versuchen haben für mich funktioniert.

In meinem Fall war es ein Verbindungsproblem. Ich war mit einem internen WLAN-Netzwerk verbunden, in dem ich nur eingeschränkten Zugriff auf Ressourcen hatte. Das ließ Git den Abruf machen, aber zu einer bestimmten Zeit stürzte es ab. Dies bedeutet, dass es sich um ein Netzwerkverbindungsproblem handeln kann. Überprüfen Sie, ob alles ordnungsgemäß ausgeführt wird: Antivirus, Firewall usw.

Die Antwort von elin3t ist daher wichtig, da ssh die Leistung des Downloads verbessert, so dass Netzwerkprobleme vermieden werden können

Die Einstellung der folgenden Konfiguration funktioniert bei mir nicht.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Als vorheriger Kommentar könnte es sich um das Speicherproblem von git handeln. Daher versuche ich, Arbeitsfäden (von 32 auf 8) zu reduzieren. Damit es nicht gleichzeitig viele Daten vom Server erhält. Dann füge ich auch "-f" hinzu, um die Synchronisierung anderer Projekte zu erzwingen.

-f: Proceed with syncing other projects even if a project fails to sync.

Dann funktioniert es jetzt gut.

repo sync -f -j8

Eine frühere Antwort empfiehlt die Einstellung auf 512 m. Ich würde sagen, es gibt Gründe zu der Annahme, dass dies bei einer 64-Bit-Architektur kontraproduktiv ist. Die Dokumentation zu core.packedGitLimit lautet:

Die Standardeinstellung ist 256 MiB auf 32-Bit-Plattformen und 32 TiB (praktisch unbegrenzt) auf 64-Bit-Plattformen. Dies sollte für alle Benutzer / Betriebssysteme angemessen sein, außer für die größten Projekte. Sie müssen diesen Wert wahrscheinlich nicht anpassen.

Wenn Sie es ausprobieren möchten, überprüfen Sie, ob Sie es eingestellt haben, und entfernen Sie dann die Einstellung:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

Beachten Sie, dass Git 2.13.x / 2.14 (Q3 2017) den Standardwert erhöht, der Folgendes core.packedGitLimitbeeinflusst git fetch:
Der Standardgrenzwert für gepackte Git wurde auf größeren Plattformen ( von 8 GiB auf 32 GiB ) erhöht , um " git fetch" vor einem (behebbaren) Fehler zu schützen während " gc" parallel läuft.

Siehe Commit be4ca29 (20. April 2017) von David Turner ( csusbdt) .
Mit freundlicher Unterstützung von Jeff King ( peff) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit d97141b , 16. Mai 2017)}

Erhöhen, ansteigen core.packedGitLimit

Wenn core.packedGitLimitüberschritten wird, schließt git die Packungen.
Wenn parallel zu einem Abruf ein Umpackvorgang ausgeführt wird, öffnet der Abruf möglicherweise ein Paket und muss es schließen, da PackedGitLimit getroffen wird.
Das Umpacken könnte dann das Paket unter dem Abruf löschen, wodurch der Abruf fehlschlägt.

Erhöhen Sie core.packedGitLimitden Standardwert, um dies zu verhindern.

Auf aktuellen 64-Bit-x86_64-Computern stehen 48 Bit Adressraum zur Verfügung.
Es scheint, dass 64-Bit-ARM-Maschinen keinen Standard-Adressraum haben (das heißt, er variiert je nach Hersteller), und IA64- und POWER-Maschinen haben die vollen 64-Bit.
48 Bit sind also die einzige Grenze, um die wir uns vernünftigerweise kümmern können. Wir reservieren ein paar Bits des 48-Bit-Adressraums für die Verwendung durch den Kernel (dies ist nicht unbedingt erforderlich, aber es ist besser, sicher zu sein) und verwenden bis zu den verbleibenden 45.
Kein Git-Repository wird zu irgendeinem Zeitpunkt annähernd so groß sein bald, so sollte dies den Ausfall verhindern.

Mit der Antwort @cmpickle habe ich ein Skript erstellt, um den Klonprozess zu vereinfachen.

Es wird hier gehostet: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Sie können es mit der folgenden Zeile ausführen:

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

In meinem Fall war das Problem keiner der Git-Konfigurationsparameter, sondern die Tatsache, dass mein Repository eine Datei hatte, die die auf meinem System maximal zulässige Dateigröße überschritt. Ich konnte es überprüfen, indem ich versuchte, eine große Datei herunterzuladen und ein "Dateigrößenlimit überschritten" für Debian zu erhalten.

Danach habe ich meine Datei /etc/security/limits.conf bearbeitet und am Ende die folgenden Zeilen hinzugefügt: * hard fsize 1000000 * soft fsize 1000000

Um die neuen Grenzwerte tatsächlich "anzuwenden", müssen Sie sich erneut anmelden

Tangential verwandt und nur nützlich, wenn Sie keinen Root-Zugriff haben und Git manuell aus einem RPM (mit rpm2cpio) oder einem anderen Paket (.deb, ..) in einen Unterordner extrahieren. Typischer Anwendungsfall: Sie versuchen, eine neuere Version von Git anstelle der veralteten Version auf einem Unternehmensserver zu verwenden.

Wenn der Git-Klon mit fatal: index-pack failed ohne frühzeitige EOF-Erwähnung, aber stattdessen mit einer Hilfemeldung fehlschlägt usage: git index-pack, liegt eine Versionsinkongruenz vor und Sie müssen Git mit dem folgenden --exec-pathParameter ausführen :

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

Damit dies automatisch geschieht, geben Sie Folgendes an ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

Ich hatte die gleichen Fehlerprotokolle mit git (v2.17.1) über ssh. In meinem Fall lautet die Lösung:

1. Betreten Sie das Git Bare Repository meines Servers.
2. Rufen Sie an git gc.

Siehe git-gc-Dokumentation: https://git-scm.com/docs/git-gc .

Z.B:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc

Jetzt kann ich dieses Repository fehlerfrei klonen, zB auf Client-Seite:

git clone git@my_server_url.com:my_repo_name

Der Befehl git gckann auf der Git-Client-Seite aufgerufen werden, um ähnliche git pushProbleme zu vermeiden .

Eine andere (Hack-) Lösung ist das Herunterladen des letzten Masters ohne Verlauf:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

Es besteht die Möglichkeit, dass kein Pufferüberlauf auftritt.

In meinem Fall funktionierte nichts, als das Protokoll https war, dann wechselte ich zu ssh und stellte sicher, dass ich das Repo aus dem letzten Commit und nicht aus dem gesamten Verlauf und auch aus einem bestimmten Zweig zog. Das hat mir geholfen:

Git-Klon - Tiefe 1 "ssh: .git" - Zweig "spezifischer Zweig"

Ich habe alle Downloads, die ich in der Zwischenzeit durchgeführt habe, deaktiviert, wodurch wahrscheinlich Speicherplatz frei wurde und die Bandbreite erhöht / verringert wurde

Das Git-Daemon-Problem scheint in Version 2.17.0 behoben worden zu sein (überprüft mit einer nicht funktionierenden Version 2.16.2.1). Das heißt, eine Problemumgehung für die Auswahl von Text in der Konsole zum "Sperren des Ausgabepuffers" sollte nicht mehr erforderlich sein.

Von https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

• Verschiedene Korrekturen an "git daemon". (füge ed15e58efe jk / daemon-fixes später zur Wartung zusammen).

Ich habe das gleiche Problem. Nach dem ersten Schritt oben konnte ich klonen, aber ich kann nichts anderes tun. Alte Zweige können nicht abgerufen, gezogen oder ausgecheckt werden.

Jeder Befehl wird viel langsamer als gewöhnlich ausgeführt und stirbt nach dem Komprimieren der Objekte.

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

Dies passiert auch, wenn Ihre Schiedsrichter zu viel Speicher verwenden. Das Beschneiden der Erinnerung hat dies für mich behoben. Fügen Sie einfach eine Grenze für das hinzu, was Sie so abrufen ->

git fetch --depth=100

Dadurch werden die Dateien abgerufen, jedoch mit den letzten 100 Änderungen in ihrem Verlauf. Danach können Sie jeden Befehl gut und mit normaler Geschwindigkeit ausführen.

Bei den meisten Antworten hier habe ich den Fehler mit dem PUTTY SSH Client mit allen möglichen Konstellationen erhalten.

Nachdem ich zu OpenSSH gewechselt war, war der Fehler behoben (entfernen Sie die Umgebungsvariable GIT_SSH und starten Sie die Git-Bash neu).

Ich habe eine neue Maschine und die neuesten Git-Versionen verwendet. Auf vielen anderen / älteren Computern (auch AWS) funktionierte es wie erwartet auch mit PUTTY ohne Git-Konfiguration.

Ich habe das gleiche Problem erlebt. Das REPO war zu groß, um über SSH heruntergeladen zu werden. Genau wie von @ elin3t empfohlen, habe ich über HTTP / HTTPS geklont und die REMOTE-URL in .git / config geändert, um das SSH-REPO zu verwenden.

Ich habe das gleiche Problem wie unten, wenn ich renne git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Dann überprüfte ich git status, ob es so viele nicht festgeschriebene Änderungen gab, dass ich das Problem durch Festschreiben und Übertragen aller nicht festgeschriebenen Änderungen behoben habe .

Keine der oben genannten Lösungen hat bei mir funktioniert.

Die Lösung, die schließlich für mich funktionierte, war das Wechseln des SSH-Clients. Die Umgebungsvariable GIT_SSH wurde auf OpenSSH festgelegt, das von Windows Server 2019 bereitgestellt wird. Version 7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

Ich habe einfach Putty installiert, 0.72

choco install putty

Und geändert GIT_SSH in

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

Ich habe so ziemlich alle hier gemachten Vorschläge ausprobiert, aber keiner hat funktioniert. Für uns war das Problem temperamentvoll und wurde immer schlimmer, je größer die Repos wurden (auf unserem Jenkins Windows Build Slave).

Es war die Version von ssh, die von git verwendet wurde. Git wurde für die Verwendung einer Version von Open SSH konfiguriert, die in der .gitconfig-Datei des Benutzers über die Variable core.sshCommand angegeben ist. Durch Entfernen dieser Zeile wurde das Problem behoben. Ich glaube, das liegt daran, dass Windows jetzt mit einer zuverlässigeren / kompatibleren Version von SSH ausgeliefert wird, die standardmäßig verwendet wird.

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

Von einem Git-Klon bekam ich:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

Nach dem Neustart meines Computers konnte ich das Repo gut klonen.

Wenn Sie unter Windows arbeiten, möchten Sie möglicherweise überprüfen, ob der Git-Klon fehlschlägt , wenn "Index-Pack" fehlgeschlagen ist. .

Grundsätzlich können Sie nach dem Ausführen Ihres git.exe daemon ...Befehls Text aus diesem Konsolenfenster auswählen. Wiederholen Sie das Ziehen / Klonen, es könnte jetzt funktionieren!

Weitere Informationen finden Sie in dieser Antwort .

Stellen Sie sicher, dass auf Ihrem Laufwerk noch genügend Speicherplatz vorhanden ist

Keines davon funktionierte für mich, aber die Verwendung von Herokus eingebautem Tool hat den Trick getan.

heroku git:clone -a myapp

Dokumentation hier: https://devcenter.heroku.com/articles/git-clone-heroku-app