Wie kann ich den Git-Fehler "Objektdatei ... ist leer" beheben?

Question

Wenn ich versuche, Änderungen zu übertragen, erhalte ich diesen Fehler:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Ich habe versucht git fsck Das habe ich:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

Wie kann ich diesen Fehler beheben?

Answer 1

Machen wir es uns einfach... nur für den Fall, dass Sie den Quellcode in ein entferntes Git-Repository hochgeladen haben

1. Sichern Sie Ihr .git Ordner

2. Prüfen Sie Ihr Git-Repository

    git fsck --full

3. Leere Objektdateien entfernen (alle)

    rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e

4. Prüfen Sie Ihr Git-Repository erneut.

    git fsck --full

5. Ziehen Sie Ihren Quellcode aus dem entfernten Git-Repository

    git pull origin master

Answer 2

Git-Objekt-Fehler beheben Lösung Führen Sie einfach den folgenden Befehl aus

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Refresh index: 100% (5322/5322), done.
error: object file .git/objects/d4/f989f0e5f4613a3cbba836b3c77dfb71a7a56c is empty
error: object file .git/objects/d4/f989f0e5f4613a3cbba836b3c77dfb71a7a56c is empty
error: object file .git/objects/d4/f989f0e5f4613a3cbba836b3c77dfb71a7a56c is empty
fatal: loose object d4f989f0e5f4613a3cbba836b3c77dfb71a7a56c (stored in .git/objects/d4/f989f0e5f4613a3cbba836b3c77dfb71a7a56c) is corrupt

Answer 3

Das passiert mir auch fast regelmäßig. Ich habe nicht genau protokolliert, wann das passiert, aber ich habe den Verdacht, dass es immer dann auftritt, wenn meine virtuelle Maschine (VM) existiert "unerwartet". Wenn ich das VM-Fenster schließe (ich verwende Ubuntu 18.04 (Bionic Beaver)) und erneut starten, funktioniert es immer(?). Aber wenn das VM-Fenster noch offen ist, wenn mein Laptop heruntergefahren wird (Windows-Host-System), dann treffe ich dieses Problem ziemlich häufig.

Zu allen hier gegebenen Antworten:

1. Ich speichere normalerweise eine lokale Kopie meines Codes, stelle das Repository aus der Ferne wieder her und verschiebe die Sicherungskopie zurück in den lokalen Ordner.

2. da das zugrundeliegende Problem nicht wirklich ein Git-Problem ist, sondern eher ein VM- und/oder Linux-Problem, frage ich mich, ob es nicht eine Möglichkeit geben sollte, die Ursache und nicht die Symptome zu beheben? Weist diese Art von Fehler nicht darauf hin, dass einige Änderungen im Dateisystem nicht in angemessener Zeit "angewendet" werden, sondern nur zwischengespeichert werden (siehe zum Beispiel Werden Dateibearbeitungen unter Linux direkt auf der Festplatte gespeichert? ) - für mich sieht es so aus, als ob virtuelle Linux-Maschinen ihre Daten nicht häufig genug fsynchronisieren. Ob dies ein Problem von Oracles VirtualBox (das ansonsten sehr gut funktioniert) oder des Gastdateisystems oder einiger Einstellungen ist, die wir alle übersehen, entzieht sich meiner Kenntnis. Aber ich würde mich freuen, wenn jemand Licht in die Sache bringen könnte.

Answer 4

Meine Kollegen und ich sind mehrmals mit dem gleichen Problem konfrontiert worden, und um es zu lösen, führen wir einfach die Schritte aus, die ich unten beschreibe. Es ist nicht die eleganteste Lösung, die gefunden werden kann, aber es funktioniert ohne Verlust von Daten.

1. Umbenennen des aktuellen Arbeitsverzeichnisses. ( old_project für dieses Beispiel).
2. Klonen Sie das Repository in ein neues Verzeichnis mit git clone .
3. Wechseln Sie in der Befehlszeile in das Arbeitsverzeichnis des neu erstellten Projekts und wechseln Sie zu dem Zweig, an dem Sie gearbeitet haben.
4. Kopieren Sie alle Dateien und Verzeichnisse innerhalb von old_project (mit Ausnahme der .git Verzeichnis) in das neu erstellte Projektverzeichnis.
5. Überprüfen Sie den Status Ihres Arbeitsbaums (beachten Sie, dass es viel mehr Änderungen gibt, als Sie erwarten) und übertragen Sie dann die Änderungen.

Ich hoffe, es hilft...

Answer 5

Ich gehe davon aus, dass Sie eine Fernbedienung haben, auf die alle relevanten Änderungen bereits übertragen wurden. Ich habe mich nicht um lokale Änderungen gekümmert und wollte einfach nur vermeiden, ein großes Repository zu löschen und neu zu klonen. Wenn Sie wichtige lokale Änderungen haben, sollten Sie vielleicht etwas vorsichtiger sein.

Ich hatte das gleiche Problem, nachdem mein Laptop abgestürzt war. Wahrscheinlich, weil es sich um ein großes Repository handelte, hatte ich ziemlich viele beschädigte Objektdateien, die nur einzeln beim Aufruf von git fsck --full Deshalb habe ich einen kleinen Shell-Einzeiler geschrieben, um einen von ihnen automatisch zu löschen:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 leitet die Fehlermeldung auf die Standardausgabe um, damit man grep es
• grep verwendeten Optionen:
• -o gibt nur den Teil einer Zeile zurück, der tatsächlich übereinstimmt
• -E ermöglicht erweiterte reguläre Ausdrücke
• -m 1 sicherstellen, dass nur der erste Treffer zurückgegeben wird
• [0-9a-f]{2} passt auf jedes der Zeichen zwischen 0 und 9 und a und f, wenn zwei davon zusammen vorkommen
• [0-9a-f]* passt auf eine beliebige Anzahl von Zeichen zwischen 0 und 9 sowie a und f, die zusammen auftreten

Es wird immer nur eine Datei auf einmal gelöscht, so dass Sie es vielleicht in einer Schleife aufrufen sollten:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

Das Problem dabei ist, dass er nichts Nützliches mehr ausgibt, so dass man nicht weiß, wann er fertig ist (er sollte einfach nach einiger Zeit nichts Nützliches mehr tun).

Um dies zu "beheben", habe ich dann einfach einen Aufruf von git fsck --full nach jeder Runde wie folgt: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Er ist jetzt etwa halb so schnell, aber er gibt seinen "Zustand" aus.

Danach habe ich ein wenig mit den Vorschlägen in den Antworten hier herumgespielt und bin schließlich zu einem Punkt gekommen, an dem ich git stash y git stash drop viel von dem kaputten Zeug.

Erstes Problem gelöst

Danach hatte ich immer noch das folgende Problem: unable to resolve reference 'refs/remotes/origin/$branch': reference broken die gelöst werden könnten durch $ rm \repo.git\refs\remotes\origin$branch

$ git fetch

Ich habe dann eine $ git gc --prune=now

$ git remote prune origin

zur Sicherheit und

git reflog expire --stale-fix --all

um loszuwerden error: HEAD: invalid reflog entry $blubb beim Laufen git fsck --full .