Fatal: vorzeitiges EOF fatal: Index-Pack fehlgeschlagen

Question

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

Ich versuche, von einer Maschine zu klonen, indem ich mich mit dem Remote-Server verbinde, der sich im LAN-Netzwerk befindet.
Das Ausführen dieses Befehls von einer anderen Maschine führt zu einem Fehler.
Aber das Ausführen des GLEICHEN Klonbefehls unter Verwendung von 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 in .gitconfig hinzugefügt, aber auch keine Hilfe.
Verwendung der Git-Version 1.8.5.2.msysgit.0

[core]
    compression = -1

Answer 1

Die Konfiguration unten funktioniert für mich nicht.

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

Wie im vorherigen Kommentar erwähnt, könnte es an einem Speicherproblem von Git liegen. Deshalb versuche ich, die Arbeitsgewinde von 32 auf 8 zu reduzieren. So werden nicht gleichzeitig viele Daten vom Server abgerufen. Dann füge ich auch "-f " hinzu, um die Synchronisierung anderer Projekte zu erzwingen.

-f: Fortfahren mit der Synchronisierung anderer Projekte, auch wenn ein Projekt nicht synchronisiert werden kann.

Dann funktioniert es jetzt einwandfrei.

repo synchronisieren -f -j8

Answer 2

Es ist verwirrend, weil Git-Protokolle möglicherweise auf beliebige Verbindungs- oder SSH-Autorisierungsfehler hinweisen, z. B .: ssh_dispatch_run_fatal: Verbindung zum x.x.x.x-Port yy fehlgeschlagen: Authentifizierungscode inkorrekt, das Remote-Ende hat unerwartet aufgelegt, frühes EOF.

Lösung auf Serverseite

Optimieren wir das Git-Repository auf der Serverseite:

1. Gehe in mein Server-Bare-Git-Repository.
2. Rufe git gc auf.
3. Rufe git repack -A auf

Z. B.:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # wo mein Server-Bare-Repository existiert.
git gc
git repack -A

Jetzt kann ich dieses Repository ohne Fehler klonen, z. B. auf der Client-Seite:

git clone git@my_server_url.com:my_repo_name

Der Befehl git gc kann auf der Git-Client-Seite aufgerufen werden, um ähnliche git push-Probleme zu vermeiden.

---

Wenn Sie ein Administrator des Gitlab-Dienstes sind - lösen Sie die Housekeeping manuell aus. Es ruft intern git gc oder git repack auf.

---

Lösung auf Clientseite

Die andere (Hack-, nur Clientseite) Lösung besteht darin, den letzten Master ohne Verlauf herunterzuladen:

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

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

Answer 3

Ein vorherige Antwort empfiehlt, dies auf 512 m festzulegen. Ich würde sagen, es gibt Gründe zu glauben, dass dies auf einer 64-Bit-Architektur kontraproduktiv ist. Die Dokumentation für core.packedGitLimit sagt:

Standardmäßig sind 256 MiB auf 32-Bit-Plattformen und 32 TiB (effektiv unbegrenzt) auf 64-Bit-Plattformen. Dies sollte für alle Benutzer/Betriebssysteme vernünftig sein, außer bei den größten Projekten. Sie müssen diesen Wert wahrscheinlich nicht anpassen.

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

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

Bearbeitung: Hier gerade einen Ouroboros-Moment, es sollte erwähnt werden, dass dies in Kombination mit der Lösung von @amirreza-moeini-yegane dieses Problem für mich heute gelöst hat.

git config --global core.compression 0

Answer 4

Beachten Sie, dass Git 2.13.x/2.14 (Q3 2017) den standardmäßigen Wert für core.packedGitLimit erhöht, der sich auf git fetch auswirkt:
Der standardmäßige Wert für das gepackte Git-Limit wurde auf größeren Plattformen erhöht (von 8 GiB auf 32 GiB), um "git fetch" vor einem (wiederherstellbaren) Ausfall während des parallelen Ausführens von "gc" zu schützen.

Siehe Commit be4ca29 (20. Apr 2017) von David Turner (csusbdt).
Unterstützt von: Jeff King (peff).
(Zusammengeführt von Junio C Hamano - gitster - in Commit d97141b, 16. Mai 2017)

Erhöhung von core.packedGitLimit

Wenn core.packedGitLimit überschritten wird, wird git Packs schließen.
Wenn eine Repack-Operation parallel zu einem Fetch erfolgt, könnte der Fetch ein Pack öffnen und dann gezwungen sein, es wieder zu schließen, weil packedGitLimit erreicht ist.
Die Repack könnte dann das Pack löschen, während der Fetch darauf zugreift, was zu einem Fehlschlag führen würde.

Erhöhen Sie den standardmäßigen Wert von core.packedGitLimit, um dies zu verhindern.

Auf aktuellen 64-Bit x86_64-Maschinen stehen 48 Adressraumbits zur Verfügung.
Es scheint, dass 64-Bit-ARM-Maschinen keine standardmäßige Adressraummenge haben (d.h. es variiert je nach Hersteller), während IA64- und POWER-Maschinen die vollen 64 Bits haben.
Daher ist 48 Bits die einzige Grenze, um die wir uns vernünftigerweise kümmern sollten. Wir behalten ein paar Bits des 48-Bit-Adressraums für den Kernel vor (das ist nicht unbedingt erforderlich, aber es ist sicherer), und verwenden bis zu den verbleibenden 45 Bits.
Kein git-Repository wird in absehbarer Zeit auch nur annähernd so groß sein, daher sollte dies einen Ausfall verhindern.

Answer 5

Ich hatte das gleiche Problem, ich habe sogar versucht, das Projekt direkt von der Website als Zip-Datei herunterzuladen, aber der Download wurde genau bei demselben Prozentsatz unterbrochen.

Diese eine Zeile hat mein Problem wie durch Zauberhand gelöst

git config --global core.compression 0

Ich weiß, dass in anderen Antworten darauf hingewiesen wurde, aber niemand hat hier erwähnt, dass allein diese Zeile das Problem beheben kann.

Ich hoffe, es hilft.