Git: "Korruptes loses Objekt"

Question

Jedes Mal, wenn ich von meiner Fernbedienung abrufe, erhalte ich die folgende Fehlermeldung zur Komprimierung. Wenn ich die manuelle Komprimierung ausführe, erhalte ich denselben Fehler:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Weiß jemand, was man dagegen tun kann?

Aus der cat-Datei erhalte ich dies:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

Und von git fsck erhalte ich dies (weiß nicht, ob es tatsächlich verwandt ist):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Kann mir jemand helfen, dies zu entschlüsseln?

Answer 1

Ich hatte das gleiche Problem (ich weiß nicht, warum).

Diese Korrektur erfordert den Zugriff auf eine unbeschädigte Remote-Kopie des Repositorys, so dass Ihre lokale Arbeitskopie intakt bleibt.

Aber es hat auch einige Nachteile:

• Sie verlieren die Aufzeichnung aller Commits, die nicht gepusht wurden, und müssen sie erneut übertragen.
• Sie werden alle Verstecke verlieren.

Die Lösung

Führen Sie diese Befehle aus dem übergeordneten Verzeichnis über Ihrem Repo aus (ersetzen Sie "foo" durch den Namen Ihres Projektordners):

1. Erstellen Sie ein Backup des beschädigten Verzeichnisses:
   cp -R foo foo-backup
2. Erstellen Sie einen neuen Klon des entfernten Repositorys in einem neuen Verzeichnis:
   git clone git@www.mydomain.de:foo foo-newclone
3. Löschen Sie das beschädigte .git-Unterverzeichnis:
   rm -rf foo/.git
4. Verschieben Sie das neu geklonte .git-Unterverzeichnis nach foo:
   mv foo-newclone/.git foo
5. Löschen Sie den Rest des temporären neuen Klons:
   rm -rf foo-newclone

Unter Windows müssen Sie diese Option verwenden:

• copy anstelle von cp -R
• rmdir /S anstelle von rm -rf
• move anstelle von mv

Jetzt hat foo seine ursprüngliche .git Unterverzeichnis zurück, aber alle lokalen Änderungen sind noch vorhanden. git status , commit , pull , push usw. funktionieren wieder so, wie sie sollten.

Answer 2

Am besten ist es wahrscheinlich, einfach vom entfernten Repository (z. B. GitHub) neu zu klonen. Leider verlieren Sie dabei alle nicht gepushten Commits und versteckten Änderungen, aber Ihre Arbeitskopie sollte intakt bleiben.

Erstellen Sie zunächst eine Sicherungskopie Ihrer lokalen Dateien. Führen Sie dies dann von der Wurzel Ihres Arbeitsbaums aus durch:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master

Übertragen Sie dann alle geänderten Dateien, sofern erforderlich.

Answer 3

Ich arbeite an einer VM auf meinem Notebook, der Akku ist leer und ich bekomme diesen Fehler;

Fehler: Objektdatei .git/objects/ce/theRef ist leer Fehler: Objekt Datei .git/objects/ce/theRef ist leer fatal: loses Objekt theRef (gespeichert in .git/objects/ce/theRef) ist beschädigt

Ich habe es geschafft, das Repo mit nur 2 Befehlen wieder zum Laufen zu bringen und ohne meine Arbeit zu verlieren (geänderte Dateien/unübertragene Änderungen)

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

Danach habe ich eine git status Das Repo war in Ordnung und es gab meine Änderungen (die darauf warten, committed zu werden, tun Sie es jetzt ).

Git-Version 1.9.1

Denken Sie daran, alle Änderungen zu sichern, nur für den Fall, dass diese Lösung nicht funktioniert und ein radikalerer Ansatz erforderlich ist.

Answer 4

Sieht aus, als hätten Sie ein beschädigtes Baumobjekt. Sie müssen dieses Objekt von jemand anderem bekommen. Hoffentlich hat dieser eine unbeschädigte Version.

Sie können es sogar rekonstruieren, wenn Sie keine gültige Version von jemand anderem finden können, indem Sie raten, welche Dateien vorhanden sein sollten. Vielleicht möchten Sie sehen, ob die Daten und Zeiten der Objekte damit übereinstimmen. Das könnten die zugehörigen Blobs sein. Von diesen Objekten könnten Sie auf die Struktur des Baumes schließen.

をご覧ください。 Scott Chacons Git-Screencasts über Git-Interna. Hier wird Ihnen gezeigt, wie Git unter der Haube funktioniert und wie Sie diese Detektivarbeit erledigen können, wenn Sie wirklich feststecken und das Objekt nicht von jemand anderem bekommen können.

Answer 5

Mein Computer ist abgestürzt, als ich gerade eine Commit-Nachricht schrieb. Nach dem Neustart war der Arbeitsbaum so, wie ich ihn verlassen hatte, und ich konnte meine Änderungen erfolgreich übertragen.

Als ich jedoch versuchte, die git status Ich habe

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

Im Gegensatz zu den meisten anderen Antworten habe ich nicht versucht, irgendwelche Daten wiederherzustellen. . Ich wollte nur, dass Git aufhört, sich über die leere Objektdatei zu beschweren.

Übersicht

Die "Objektdatei" ist Gits gehashte Darstellung einer realen Datei, die Ihnen wichtig ist. Git denkt, dass es eine gehashte Version von some/file.whatever gespeichert in .git/object/xx/12345 und es stellte sich heraus, dass die Behebung des Fehlers vor allem darin bestand, herauszufinden, welche Datei das "lose Objekt" darstellen sollte.

Einzelheiten

Mögliche Optionen schienen zu sein

1. Löschen Sie die leere Datei
2. Die Datei in einen für Git akzeptablen Zustand bringen

Ansatz 1: Entfernen der Objektdatei

Als erstes habe ich versucht, die Objektdatei zu verschieben

mv .git/objects/xx/12345 ..

Das funktionierte nicht - Git begann sich über einen defekten Link zu beschweren. Weiter zu Ansatz 2.

Ansatz 2: Reparieren der Datei

Linus Torvalds hat einen großartigen Bericht über wie man eine Objektdatei wiederherstellt Damit war das Problem für mich gelöst. Die wichtigsten Schritte sind hier zusammengefasst.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

Dies sagt Ihnen, von welcher Datei das leere Objekt ein Hash sein soll. Jetzt können Sie es reparieren.

$> git hash-object -w path/to/your_file.whatever

Nachdem ich dies getan hatte, überprüfte ich .git/objects/xx/12345 war es nicht mehr leer, und Git hörte auf, sich zu beschweren.