Vor ein paar Wochen hatte ich ein sehr ungewöhnliches Problem mit Git. In einem Repository, mit dem ich schon länger nicht mehr gearbeitet hatte, sollte ich mir mit git status ansehen, was ich zuletzt gemacht hatte, und bekam folgendes Ergebnis:
$ git status
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
fatal: Loses Objekt 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (gespeichert in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) ist beschädigt.
Das hatte ich bisher noch nie bekommen. Zum Glück gibt es von Git einen Befehl, mit dem man den Zustand des Dateisystems überprüfen kann.
$ git fsck --full
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Konnte mmap nicht auf .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ausführen.: Datei oder Verzeichnis nicht gefunden
error: 6eeab7d4770c705a0491cafbc95830af69d5c6a2: Objekt fehlerhaft oder nicht vorhanden: .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2
Prüfe Objekt-Verzeichnisse: 100% (256/256), fertig.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
error: Objektdatei .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2 ist leer.
fatal: Loses Objekt 6eeab7d4770c705a0491cafbc95830af69d5c6a2 (gespeichert in .git/objects/6e/eab7d4770c705a0491cafbc95830af69d5c6a2) ist beschädigt.
Das hat mir ein wenig mehr Informationen zum Fehler geben, aber leider noch immer keine Lösung dazu, wie es Git oft macht, wenn man ein Kommando verwendet.
Die Lösung
Mit diesen neuen Informationen konnte ich mich dann aber auf die Suche machen und eine Lösung bei Stack Overflow finden. Ich musste hierzu lediglich die beschädigte/leere Datei löschen. In meinem Fall war es wirklich nur diese eine Datei, wenn man aber in einem Git Repository mehrere solche Dateien hat, dann kann man mit dem folgenden Befehl recht schnell alle „leeren“ Dateien im Git-Ordner löschen:
$ find .git/objects/ -type f -empty | xargs rm
Nach der Ausführung dieses Befehls fehlen dann natürlich all diese Dateien im Repository. Diese bekommt man schnell wieder zurück, indem man sie von einem Remote lädt:
After this command, all corrupt files are missing from the repository. We can get them back by fetching the data from the remote:
$ git fetch -p
remote: Enumerating objects: 228, done.
remote: Counting objects: 100% (228/228), done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 210 (delta 121), reused 188 (delta 99), pack-reused 0
Empfange Objekte: 100% (210/210), 90.23 KiB | 1.43 MiB/s, fertig.
Löse Unterschiede auf: 100% (121/121), abgeschlossen mit 11 lokalen Objekten.
Zuletzt können wir noch einmal eine Dateisystem-Prüfung machen und kontrollieren, ob nun alle Fehler behoben wurden:
$ git fsck --full
Prüfe Objekt-Verzeichnisse: 100% (256/256), fertig.
Prüfe Objekte: 100% (221/221), fertig.
blob c5446110414804bbba2a5316a3e996ff37666bb9 unreferenziert
blob 45dd1301284105bcfc7e183bc805b65bf1465f47 unreferenziert
blob 70376fcbe5060d0db11490249bed5b553c0d04cc unreferenziert
Fazit
Normalerweise gibt uns Git immer sehr hilfreiche Fehlermeldungen, wenn wir etwas falsch machen. In diesem Fall musste ich aber ein wenig recherchieren, um eine Lösung zu finden. Zum Glück hatten schon andere vor mir das gleiche Problem und konnten es lösen.
Unsere Lösung hat aber nur deshalb ohne Verluste funktioniert, weil wir die beschädigten/leeren Objekte von einem Remote neu laden konnten. Daher empfehle ich Leuten immer, dass sie ihren Code auch in einem Remote Repository haben sollten und häufigen Committen und Pushen.