it-swarm.com.de

tödlich: früh EOF fatal: Index-Pack fehlgeschlagen

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

Ich versuche, von einem Computer aus zu klonen, indem ich mich mit dem Remote-Server im LAN-Netzwerk verbinde.
Das Ausführen dieses Befehls von einem anderen Computer verursacht einen Fehler.
Das Ausführen des SAME-Klonbefehls mit git: //192.168.8.5 ... auf dem Server ist in Ordnung und erfolgreich. 

Irgendwelche Ideen ?

[email protected] ~
$ 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 Konfig in .gitconfig hinzugefügt, aber auch keine Hilfe.
Verwenden der git-Version 1.8.5.2.msysgit.0

[core]
    compression = -1
198
William

Deaktivieren Sie zunächst die Komprimierung: 

git config --global core.compression 0

Als nächstes wollen wir einen partiellen Klon machen, um die Informationsmenge abzuschneiden: 

git clone --depth 1 <repo_URI>

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

git fetch --unshallow 

oder alternativ 

git fetch --depth=2147483647

Führen Sie nun einen regelmäßigen Zug aus: 

git pull --all

Ich denke, es gibt eine Störung mit msysgit in den 1.8.x-Versionen, die diese Symptome verschlimmert. Eine andere Möglichkeit ist, es mit einer früheren Version von git zu versuchen (<= 1.8.3, denke ich). 

394
ingyhere

Dieser Fehler kann für den Speicherbedarf von git auftreten. Sie können diese Zeilen zu Ihrer globalen Git-Konfigurationsdatei hinzufügen, die .gitconfig in $USER_HOME lautet, um das Problem zu beheben.

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

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

Aus einem BitBucket-Ausgabe-Thread:

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

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

git config --global core.compression 9

Aus der Git-Dokumentation:

core.compression
Eine Ganzzahl -1..9, die eine Standardkomprimierung angibt Niveau. -1 ist der Zlib-Standard.
0 bedeutet keine Komprimierung und 1..9 sind verschiedene Geschwindigkeits-/Größen-Kompromisse, wobei 9 am langsamsten ist.
Wenn gesetzt, wird ein .__ bereitgestellt. Standardmäßig werden andere Kompressionsvariablen verwendet, z. B. core.looseCompression und pack.compression.

7
Jacky

Ich habe diese Fehlermeldung erhalten, als git der Speicher ausgeht.

Etwas Speicher freizugeben (in diesem Fall: einen Compilierungsjob beenden lassen) und erneut versuchen, hat bei mir funktioniert.

5
André Laszlo

In meinem Fall war das sehr hilfreich:

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

Dadurch wird die Kasse auf den angegebenen Zweig beschränkt und der Vorgang wird somit beschleunigt.

Hoffe das wird helfen.

4
sMajeed

Ich habe alle Befehle ausprobiert und keiner funktioniert für mich, aber was funktioniert, war die Änderung von git_url in http statt ssh

wenn ist der Klonbefehl:

git clone <your_http_or_https_repo_url> 

wenn Sie ein bestehendes Repo verwenden, tun Sie dies mit

git remote set-url Origin <your_http_or_https_repo_url>

hoffe das hilft jemandem!

4
elin3t

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 war, git den Abruf erledigen zu lassen, aber zu einem bestimmten Zeitpunkt stürzte er ab .. Dies bedeutet, dass es ein Problem mit der Netzwerkverbindung sein kann. Überprüfen Sie, ob alles ordnungsgemäß läuft: Antivirus, Firewall usw.

Die Antwort von elin3t ist daher wichtig, da ssh die Leistung beim Herunterladen verbessert, sodass Netzwerkprobleme vermieden werden können

4
iberbeu

Wie @ingyhere sagte:

Shallow Clone

Deaktivieren Sie zunächst die Komprimierung:

git config --global core.compression 0

Als nächstes wollen wir einen partiellen Klon machen, um die Informationsmenge abzuschneiden:

git clone --depth 1 <repo_URI>

Wenn dies 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 einen Zug machen:

git pull --all

Dann lösen Sie das Problem Ihrer lokalen Filiale nur mit Tracking-Master

Öffnen Sie Ihre Git-Konfigurationsdatei (.git/config) in einem 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/*

Machen Sie einen Git-Abruf und Git zieht jetzt alle Ihre entfernten Zweige

3
cmpickle

In einer früheren Antwort wurde die Einstellung auf 512 m empfohlen. Ich würde sagen, es gibt Gründe zu der Annahme, dass dies bei einer 64-Bit-Architektur kontraproduktiv ist. Die Dokumentation für core.packedGitLimit sagt:

Die Standardeinstellung beträgt 256 MiB auf 32-Bit-Plattformen und 32 TiB (praktisch unbegrenzt) auf 64-Bit-Plattformen. Dies sollte für alle Benutzer/Betriebssysteme mit Ausnahme der größten Projekte zumutbar sein. 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
1
8DH

Die meisten Antworten ausprobiert, ich habe den Fehler mit dem PuTTY SSH-Client mit allen möglichen Konstellationen erhalten.

Sobald ich auf OpenSSH umgestiegen bin war der Fehler weg (entferne die Umgebungsvariable GIT_SSH und starte die git bash neu).

Ich benutzte eine neue Maschine und neueste Git-Versionen. Auf vielen anderen/älteren Maschinen (auch AWS) funktionierte es mit PuTTY wie erwartet auch ohne Git-Konfiguration.

0
Max

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

Jeder Befehl läuft viel langsamer als gewöhnlich 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 geschieht auch, wenn Ihre Refs zu viel Speicher verwenden. Durch das Beschneiden der Erinnerung wurde das für mich behoben. Fügen Sie einfach ein Limit hinzu, was Sie so wollen -> 

git fetch --depth=100

Dadurch werden die Dateien mit den letzten 100 Änderungen in ihren Historien abgerufen ..__ Danach können Sie jeden Befehl problemlos und mit normaler Geschwindigkeit ausführen.

0
Vishav Premlall

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.

0
Rodel

Das git-daemon-Problem scheint in v2.17.0 gelöst worden (verifiziert mit einer nicht funktionierenden Version 2.16.2.1) . I.e. Umgehung der 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 Fixes für "git daemon" . (Ed15e58efe jk/daemon-Fixes später mit maint zusammenführen).
0
GreenMoose

In meinem Fall funktionierte nichts, wenn das Protokoll https war, dann wechselte ich zu ssh und stellte sicher, dass ich das Repo vom letzten Commit und nicht von der gesamten Historie und auch von einem bestimmten Zweig abzog. Das hat mir geholfen:

git clone --depth 1 "ssh: .git" --branch "specific_branch"

0
Shripada

Ich habe alle Downloads, die ich in der Zwischenzeit gemacht habe, deaktiviert, was wahrscheinlich etwas Speicherplatz frei gemacht hat und die Bandbreite auf- bzw. abgeregelt hat

0

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

0

Ich habe das gleiche Problem wie unten, als ich git pull ausführe.

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 habe ich den git status überprüft. Es gab so viele nicht festgeschriebene Änderungen, dass ich das Problem durch Festschreiben und Push alle nicht festgeschriebenen Änderungen behoben habe.

0
Kiran Reddy

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

commit be4ca29 (20 Apr 2017) von David Turner (csusbdt) .
Geholfen hat: Jeff King (peff) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in commit d97141b , 16. Mai 2017)

core.packedGitLimit erhöhen

Wenn core.packedGitLimit überschritten wird, schließt git die Pakete.
Wenn eine Umpackung parallel zu einem Abruf ausgeführt wird, wird der Abruf kann ein Paket öffnen und dann gezwungen werden, das Paket zu schließen, da gepacktesGitLimit getroffen wird.
Das Umpacken könnte dann das Paket unter dem Abruf löschen, wodurch der Abruf fehlschlägt.

Erhöhen Sie den Standardwert von core.packedGitLimit, um dies zu verhindern.

Bei aktuellen 64-Bit-x86_64-Maschinen stehen 48 Bit Adressraum zur Verfügung.
Es hat den Anschein, dass 64-Bit ARM -Maschinen keinen standardmäßigen Adreßraum haben (d. H. Je nach Hersteller variieren) und IA64- und POWER-Maschinen die vollen 64 Bit haben.
48 Bits 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 des Kernels (dies ist nicht unbedingt Notwendig, aber es ist besser, sicher zu sein), und verbrauchen bis zu den verbleibenden 45.
Kein Git-Repository wird in naher Zukunft irgendwo in der Nähe sein, daher sollte dies den Ausfall verhindern.

0
VonC