it-swarm.com.de

Git: "Beschädigtes loses Objekt"

Immer wenn ich von meiner Fernbedienung abziehe, erhalte ich die folgende Fehlermeldung über die Komprimierung. Wenn ich die manuelle Komprimierung durchführe, bekomme ich dasselbe:

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

Weiß jemand, was man dagegen tun soll?

Von cat-file bekomme ich folgendes: 

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

Und von git fsck bekomme ich das (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, das zu entziffern?

260
asgerhallas

Sieht aus, als hätten Sie ein beschädigtes Baumobjekt. Sie müssen dieses Objekt von einer anderen Person erhalten. Hoffentlich haben sie eine unverfälschte Version.

Sie könnten es tatsächlich rekonstruieren, wenn Sie von einer anderen Person keine gültige Version finden können, indem Sie raten, welche Dateien vorhanden sein sollen. Möglicherweise möchten Sie überprüfen, ob Datum und Uhrzeit der Objekte übereinstimmen. Das könnten die verwandten Blobs sein. Sie können die Struktur des Baumobjekts aus diesen Objekten ableiten.

Werfen Sie einen Blick auf Scott Chacons Git Screencasts bezüglich Git-Interna. Dies wird Ihnen zeigen, wie git unter der Haube arbeitet und wie Sie diese Detektivarbeit erledigen können, wenn Sie wirklich stecken bleiben und dieses Objekt nicht von jemand anderem bekommen können.

54
Adam Dymitruk

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

Dieses Update erfordert den Zugriff auf eine unbeschädigte Remote-Kopie des Repositorys und Ihre lokal arbeitende Kopie bleibt erhalten.

Aber es hat einige Nachteile:

  • Sie verlieren die Aufzeichnung aller Commits, die nicht gepusht wurden, und müssen sie erneut angeben.
  • Sie werden alle Vorräte verlieren.

Die Reparatur

Führen Sie diese Befehle aus dem übergeordneten Verzeichnis oberhalb Ihres Repos aus (ersetzen Sie 'foo' durch den Namen Ihres Projektordners):

  1. Erstellen Sie eine Sicherung des beschädigten Verzeichnisses:
    cp -R foo foo-backup
  2. Erstellen Sie einen neuen Klon aus dem Remote-Repository in ein neues Verzeichnis:
    git clone [email protected]:foo foo-newclone
  3. Löschen Sie das beschädigte .git-Unterverzeichnis:
    rm -rf foo/.git
  4. Verschieben Sie das neu geklonte .git-Unterverzeichnis in 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 Folgendes verwenden:

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

Jetzt hat foo sein .git-Unterverzeichnis zurück, aber alle lokalen Änderungen sind immer noch vorhanden. git status, commit, pull, Push usw. funktionieren wieder wie vorgesehen.

296
cubic lettuce

Ihre beste Wette ist wahrscheinlich, einfach aus dem Remote-Repo (z. B. Github oder einem anderen) erneut zu klonen. Leider gehen Sie alle nicht gelöschten Commits und Änderungen verloren, Ihre Arbeitskopie sollte jedoch erhalten bleiben.

Erstellen Sie zuerst eine Sicherungskopie Ihrer lokalen Dateien. Dann tun Sie dies von der Wurzel Ihres Arbeitsbaums aus

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  

Übernehmen Sie anschließend ggf. geänderte Dateien.

188
user1055643

Beim Arbeiten an einer virtuellen Maschine in meinem Notebook ist der Akku gestorben, dieser Fehler wurde angezeigt.

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

Es gelang mir, das Repo mit nur zwei Befehlen wieder zum Laufen zu bringen und ohne meine Arbeit zu verlieren (geänderte Dateien/nicht festgeschriebene Änderungen)

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

Danach habe ich einen git status ausgeführt, das Repo war in Ordnung und es gab meine Änderungen (die darauf warten, festgeschrieben zu werden, tun Sie es jetzt ..).

git-Version 1.9.1

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

92
Felipe Pereira

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

Als ich jedoch git status ausführen wollte, bekam ich

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 versuchte ich nicht, Daten wiederherzustellen. Ich brauchte nur Git, um sich über die leere Objektdatei zu beschweren.

Überblick

Die "Objektdatei" ist die Hash-Darstellung einer echten Datei, die Sie interessieren. Git denkt, es sollte eine gehashte Version von some/file.whatever in .git/object/xx/12345 gespeichert sein, und das Beheben des Fehlers stellte sich meistens als Frage heraus, welche Datei das "lose Objekt" darstellen sollte.

Einzelheiten

Mögliche Optionen schienen zu sein

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

Ansatz 1: Entfernen Sie die Objektdatei

Als erstes habe ich versucht, die Objektdatei zu verschieben

mv .git/objects/xx/12345 ..

Das hat nicht funktioniert - git fing an, sich über eine defekte Verbindung zu beklagen. Auf die Annäherung 2.

Ansatz 2: Reparieren Sie die Datei

Linus Torvalds hat eine großartige Beschreibung von wie man eine Objektdatei wiederherstellt die das Problem für mich gelöst hat. 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

Danach überprüfte ich .git/objects/xx/12345, es war nicht mehr leer und git hörte auf zu meckern.

37
declan

Versuchen

git stash

Das hat bei mir funktioniert. Es enthält alles, was Sie nicht begangen haben und das Problem umgangen hat.

12
Arthur

Eine Müllsammlung mein Problem behoben:

git gc --aggressive --Prune=now

Es dauert eine Weile, bis der Vorgang abgeschlossen ist, aber jedes lose Objekt und/oder der beschädigte Index wurde behoben.

4
Jago

Ich habe das gerade erlebt - mein Computer stürzte beim Schreiben in das Git-Repo ab, und er wurde beschädigt. Ich habe es wie folgt behoben.

Ich habe mit dem Anschauen begonnen, wie viele Commits ich nicht auf das Remote-Repo geschoben hatte.

gitk &

Wenn Sie dieses Tool nicht verwenden, ist es sehr praktisch - es ist, soweit ich weiß, auf allen Betriebssystemen verfügbar. Dies zeigte an, dass meiner Fernbedienung zwei Commits fehlten. Ich habe daher auf das Label geklickt, das den letzten Remote-Commit angibt (normalerweise /remotes/Origin/master), um den Hashwert zu erhalten (der Hashwert ist 40 Zeichen lang, aber aus Gründen der Kürze verwende ich hier 10 - dies funktioniert normalerweise trotzdem).

Hier ist es:

14c0fcc9b3

Ich klicke dann auf den folgenden Commit (d. H. Den ersten, den die Fernbedienung nicht hat) und bekomme den Hash dort:

04d44c3298

Ich verwende dann beide, um einen Patch für dieses Commit zu erstellen:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Ich habe es dann auch mit dem anderen fehlenden Commit gemacht, d. H. Ich habe den Hash des Commits vor und den Hash des Commits selbst verwendet:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Ich bin dann in ein neues Verzeichnis gezogen und habe das Repo von der Fernbedienung geklont:

git clone [email protected]:username/repo.git

Ich habe dann die Patch-Dateien in den neuen Ordner verschoben und sie angewendet und mit ihren genauen Commit-Meldungen festgeschrieben (diese können aus git log oder dem gitk-Fenster eingefügt werden):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Dies hat Dinge für mich wiederhergestellt (und beachten Sie, dass es wahrscheinlich eine schnellere Möglichkeit gibt, dies für eine große Anzahl von Commits zu tun). Ich war jedoch gespannt, ob der Baum im beschädigten Repo repariert werden kann, und die Antwort ist, dass er es kann. Führen Sie den Befehl mit einem reparierten Repo wie oben beschrieben im fehlerhaften Ordner aus:

git fsck 

Sie werden so etwas bekommen:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Um die Reparatur durchzuführen, würde ich dies in dem defekten Ordner tun:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

die beschädigte Datei entfernen und durch eine gute ersetzen. Möglicherweise müssen Sie dies mehrmals tun. Schließlich gibt es einen Punkt, an dem Sie fsck ohne Fehler ausführen können. Sie werden im Bericht wahrscheinlich "Dangling Commit" - und "Dangling-Blob" -Zeilen haben. Diese sind eine Folge Ihrer Rebolas und Ergänzungen in diesem Ordner und sind in Ordnung. Der Garbage Collector wird sie zu gegebener Zeit entfernen.

Ein beschädigter Baum bedeutet (zumindest in meinem Fall) nicht, dass nicht gepushte Commits verloren gehen.

4
halfer

Als Antwort auf @ user1055643 fehlt der letzte Schritt:

$ rm -fr .git
$ git init
$ git remote add Origin your-git-remote-url
$ git fetch
$ git reset --hard Origin/master
$ git branch --set-upstream-to=Origin/master master  

Ich habe auch einen fehlerhaften Objektfehler erhalten.

./objects/x/x

Ich habe es erfolgreich behoben, indem ich in das Verzeichnis des beschädigten Objekts ging. Ich habe gesehen, dass die diesem Objekt zugewiesenen Benutzer nicht mein git-Benutzer waren. Ich weiß nicht, wie es passiert ist, aber ich habe einen chown git:git für diese Datei ausgeführt und dann hat es wieder funktioniert.

Dies kann eine mögliche Lösung für die Probleme einiger Menschen sein, ist aber nicht für alle notwendig.

3
Dez

Ich habe diese Fehlermeldung erhalten, nachdem sich mein (Windows-) Computer für einen Neustart entschieden hatte ..__ Zum Glück war mein Remote-Repo auf dem neuesten Stand, also habe ich gerade einen frischen Git-Klon gemacht.

2
Dean Rather

Ich folgte vielen anderen Schritten hier; Besonders hilfreich war die Beschreibung von Linus, wie man den Git-Baum/die Objekte betrachtet und findet, was fehlt. git-git den beschädigten Blob wiederherstellen

Am Ende hatte ich jedoch lose oder beschädigte Baumobjekte, die durch einen teilweisen Festplattenfehler verursacht wurden, und Baumobjekte lassen sich nicht so leicht wiederherstellen oder werden von diesem Dokument nicht abgedeckt.

Am Ende habe ich den widersprüchlichen objects/<ha>/<hash> aus dem Weg geräumt und git unpack-objects mit einer Packdatei aus einem einigermaßen aktuellen Clone verwendet. Die fehlenden Baumobjekte konnten wiederhergestellt werden.

Ich verließ mich immer noch mit einer Menge baumelnder Blobs, was eine Nebenwirkung beim Auspacken von zuvor archivierten Dingen sein kann, und wurde in anderen Fragen angesprochen hier

2
davenpcj

Ich habe das so gelöst: Ich entschied mich einfach, die unbeschädigte Objektdatei vom Klon des Backups in mein ursprüngliches Repository zu kopieren. Das hat genauso gut funktioniert. (Übrigens: Wenn Sie das Objekt in .git/objects/nicht anhand seines Namens finden können, wurde es wahrscheinlich [gepackt] [pack], um Platz zu sparen.)

1
mcginn

Für mich geschah dies aufgrund eines Stromausfalls während eines git Push.

Die Nachrichten sahen so aus:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Ich habe Dinge wie git fsck ausprobiert, aber das hat nicht geholfen. Da der Absturz während eines git Push-Vorfalls stattfand, ist dies offensichtlich während des Umschreibens auf der Clientseite geschehen, was nach der Aktualisierung des Servers geschieht. Ich schaute mich um und stellte fest, dass c2388 in meinem Fall ein Commit-Objekt war, da in .git/refs auf Einträge verwiesen wurde. Ich wusste also, dass ich c2388 finden könnte, wenn ich die Historie anschaue (über ein Webinterface oder einen zweiten Klon).

Beim zweiten Klon habe ich einen git log -n 2 c2388 durchgeführt, um den Vorgänger von c2388 zu identifizieren. Dann habe ich .git/refs/heads/master und .git/refs/remotes/Origin/master manuell geändert, um der Vorgänger von c2388 anstelle von c2388..__ zu sein. Dann könnte ich einen git fetch..__ machen. Der git fetch schlug einige Male bei Konflikten mit leeren Objekten fehl. Ich habe jedes dieser leeren Objekte entfernt, bis git fetch erfolgreich war. Das hat das Repository geheilt.

1
Christian Hujer

Das Ausführen von git stash; git stash pop hat mein Problem behoben

1
Simonluca Landi

einfach einen git Prune laufen zu lassen, hat dieses Problem für mich behoben

0
Tyler Gauch

Wir hatten gerade den Fall hier. Es kam vor, dass das Problem darin bestand, dass der Besitz der beschädigten Datei root war und nicht unser normaler Benutzer. Dies wurde durch ein Commit auf dem Server verursacht, nachdem jemand ein "Sudo su -" ausgeführt hat.

Identifizieren Sie zunächst Ihre beschädigte Datei mit:

$> git fsck --full

Sie sollten eine Antwort wie diese erhalten:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Gehen Sie in den Ordner, in dem sich die beschädigte Datei befindet, und führen Sie Folgendes aus:

$> ls -la

Überprüfen Sie den Besitz der beschädigten Datei. Wenn das nicht der Fall ist, kehren Sie einfach zur Wurzel Ihres Repos zurück und führen Sie Folgendes aus:

$> Sudo chown -R YOURCORRECTUSER:www-data .git/

Ich hoffe es hilft!

0
Thomas Lobjoie

Bei diesem Problem habe ich meine letzten Änderungen gesichert (da ich wusste, was ich geändert hatte) und dann die Datei gelöscht, über die sie sich in .git/location beschwert hat. Dann habe ich einen Trottel gezogen. Passen Sie jedoch auf, dass dies für Sie möglicherweise nicht funktioniert.

0
gareth

Ich hatte gerade so ein Problem. Mein spezielles Problem wurde durch einen Systemabsturz verursacht, der den letzten Commit (und damit auch den Master-Zweig) beschädigt hat. Ich hatte nicht gedrängt und wollte dieses Commit wiederholen. In meinem speziellen Fall konnte ich damit umgehen:

  1. Erstellen Sie eine Sicherungskopie von .git/: rsync -a .git/ git-bak/
  2. Überprüfen Sie .git/logs/HEAD und suchen Sie die letzte Zeile mit einer gültigen Festschreibungs-ID. Für mich war dies das zweitletzte Engagement. Das war gut, weil ich immer noch die Arbeitsverzeichnisversionen der Datei hatte und somit jede Version, die ich wollte.
  3. Machen Sie bei diesem Commit eine Verzweigung: git branch temp <commit-id>
  4. wiederholen Sie den fehlerhaften Commit mit den Dateien im Arbeitsverzeichnis.
  5. git reset master temp, um den Master-Zweig in das neue Commit zu verschieben, das Sie in Schritt 2 vorgenommen haben.
  6. git checkout master und vergewissern Sie sich, dass es mit git log richtig aussieht.
  7. git branch -d temp.
  8. git fsck --full, und es sollte jetzt sicher sein, alle beschädigten Objekte zu löschen, die fsck findet. 
  9. Wenn alles gut aussieht, versuchen Sie es zu drücken. Wenn das geht, 

Das hat für mich funktioniert. Ich vermute, dass dies ein ziemlich häufig vorkommendes Szenario ist, da das letzte Commit das wahrscheinlichste ist, das beschädigt wird. Wenn Sie jedoch einen weiter zurück verlieren, können Sie wahrscheinlich immer noch eine Methode wie diese verwenden, wobei git cherrypick und der reflog in .git/logs/HEAD.

0
naught101

Ich hatte das gleiche Problem in meinem nackten Remote-Git-Repo. Nach langer Fehlerbehebung fand ich heraus, dass einer meiner Kollegen einen Commit ausgeführt hatte, in dem einige Dateien in .git/objects Berechtigungen von 440 (r - r -----) anstelle von 444 (r - r - r) hatten -). Nachdem der Mitarbeiter gebeten wurde, die Berechtigungen mit "chmod 444 -R objects" im Bare-Git-Repo zu ändern, wurde das Problem behoben.

0
konyak