Immer wenn ich von meiner Fernbedienung ziehe, wird der folgende Fehler bezüglich der Komprimierung angezeigt. Wenn ich die manuelle Komprimierung ausführe, erhalte 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?

Aus der Katzendatei 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?

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

Sie könnten es tatsächlich rekonstruieren, wenn Sie keine gültige Version von jemand anderem finden, indem Sie raten, welche Dateien dort sein sollten. Möglicherweise möchten Sie sehen, ob Datum und Uhrzeit der Objekte mit diesen übereinstimmen. Das könnten die verwandten Blobs sein. Sie können die Struktur des Baumobjekts aus diesen Objekten ableiten.

Schauen Sie sich Scott Chacons Git-Screencasts zu Git-Interna an. Dies zeigt Ihnen, wie Git unter der Haube funktioniert und wie Sie diese Detektivarbeit erledigen, wenn Sie wirklich festsitzen und dieses Objekt nicht von jemand anderem bekommen können.

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

Dieser Fix erfordert Zugriff auf eine unbeschädigte Remote-Kopie des Repositorys und behält Ihre lokal funktionierende Kopie bei.

Aber es hat einige Nachteile:

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

Die Reparatur

Führen Sie diese Befehle aus dem übergeordneten Verzeichnis über Ihrem Repo 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 des Remote-Repositorys in einem neuen Verzeichnis:
   git clone git@www.mydomain.de:foo foo-newclone
3. Löschen Sie das beschädigte Unterverzeichnis .git:
   rm -rf foo/.git
4. Verschieben Sie das neu geklonte Unterverzeichnis .git 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 anstatt cp -R
• rmdir /S anstatt rm -rf
• move anstatt mv

Jetzt hat foo sein ursprüngliches .gitUnterverzeichnis wieder, aber alle lokalen Änderungen sind noch vorhanden. git status, commit, pull, pushEtc. Arbeit wieder , wie sie sollten.

Ihre beste Wette ist wahrscheinlich, einfach vom Remote-Repo (dh Github oder einem anderen) erneut zu klonen. Leider verlieren Sie nicht gepuschte Commits und versteckte Änderungen, Ihre Arbeitskopie sollte jedoch intakt bleiben.

Erstellen Sie zunächst 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 dann alle geänderten Dateien nach Bedarf.

Bei der Arbeit an einer VM in meinem Notebook ist die Batterie leer und dieser Fehler aufgetreten.

Fehler: Objektdatei .git / Objekte / ce / theRef ist leer Fehler: Objektdatei .git / Objekte / ce / theRef ist leer fatal fatal: loses Objekt theRef (gespeichert in .git / Objekte / 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 / nicht festgeschriebene Änderungen)

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

Danach lief ich ein git status, das Repo war in Ordnung und es gab meine Änderungen (warten darauf, festgeschrieben zu werden, mach 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.

Mein Computer stürzte ab, während ich eine Festschreibungsnachricht schrieb. Nach dem Neustart war der Arbeitsbaum so, wie ich ihn verlassen hatte, und ich konnte meine Änderungen erfolgreich festschreiben.

Als ich jedoch versuchte zu rennen, git statusbekam 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 habe ich nicht versucht, Daten wiederherzustellen . Ich brauchte nur Git, um mich nicht mehr über die leere Objektdatei zu beschweren.

Überblick

Die "Objektdatei" ist die Hash-Darstellung einer realen Datei, die Sie interessiert. Git ist der Meinung, dass eine Hash-Version von some/file.whatevergespeichert sein sollte .git/object/xx/12345, und es stellte sich heraus, dass es hauptsächlich darum ging, herauszufinden, welche Datei das "lose Objekt" darstellen sollte, um den Fehler zu beheben.

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

Das erste, was ich versuchte, war nur das Verschieben der Objektdatei

mv .git/objects/xx/12345 ..

Das hat nicht funktioniert - Git hat angefangen, sich über einen defekten Link zu beschweren. Weiter zu Ansatz 2.

Ansatz 2: Korrigieren Sie die Datei

Linus Torvalds hat eine großartige Beschreibung, 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

Hier erfahren Sie, 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 das getan hatte, überprüfte ich .git/objects/xx/12345, dass es nicht mehr leer war und Git hörte auf, sich zu beschweren.

Versuchen

git stash

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

Eine Speicherbereinigung hat mein Problem behoben:

git gc --aggressive --prune=now

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

git pruneIch habe einfach ein Problem behoben, das für mich behoben wurde

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

Ich begann damit, mir anzusehen, wie viele Commits ich nicht auf das Remote-Repo übertragen hatte, also:

gitk &

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

Hier ist es:

14c0fcc9b3

Ich klicke dann auf das folgende Commit (dh das erste, das die Fernbedienung nicht hat) und erhalte dort den Hash:

04d44c3298

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

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Ich habe es dann ebenfalls mit dem anderen fehlenden Commit gemacht, dh ich habe den Hash des Commits vorher und den Hash des Commits selbst verwendet:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

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

git clone git@github.com:username/repo.git

Ich habe dann die Patch-Dateien in den neuen Ordner verschoben, sie angewendet und mit ihren genauen Festschreibungsnachrichten festgeschrieben (diese können aus git logoder über das gitkFenster eingefügt werden ):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Dies stellte die Dinge für mich wieder her (und beachten Sie, dass es wahrscheinlich einen schnelleren Weg 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 lautet, dass dies möglich ist. Führen Sie diesen Befehl in dem beschädigten Ordner aus, wenn ein repariertes Repo wie oben verfügbar ist:

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 kaputten Ordner tun:

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

dh entfernen Sie die beschädigte Datei und ersetzen Sie sie durch eine gute. Möglicherweise müssen Sie dies mehrmals tun. Schließlich wird es einen Punkt geben, an dem Sie fsckfehlerfrei laufen können. Der Bericht enthält wahrscheinlich die Zeilen "Dangling Commit" und "Dangling Blob". Diese sind eine Folge Ihrer Rebases und Änderungen in diesem Ordner und in Ordnung. Der Garbage Collector wird sie zu gegebener Zeit entfernen.

Daher bedeutet (zumindest in meinem Fall) ein beschädigter Baum nicht, dass nicht gepusste Commits verloren gehen.

Ich habe auch einen beschädigten Fehler mit losen Objekten erhalten.

./objects/x/x

Ich habe es erfolgreich behoben, indem ich in das Verzeichnis des beschädigten Objekts gegangen bin. Ich habe gesehen, dass die diesem Objekt zugewiesenen Benutzer nicht meine Git-Benutzer waren. Ich weiß nicht, wie es passiert ist, aber ich habe eine chown git:gitDatei ausgeführt und dann hat es wieder funktioniert.

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

Ich habe diesen Fehler erhalten, nachdem mein (Windows-) Computer beschlossen hat, sich selbst neu zu starten. Zum Glück war mein Remote-Repo auf dem neuesten Stand, also habe ich gerade einen neuen Git-Klon gemacht.

Runnning hat git stash; git stash popmein Problem behoben

Ich bin vielen anderen Schritten hier gefolgt; Besonders hilfreich war Linus 'Beschreibung, wie man den Git-Baum / die Objekte betrachtet und herausfindet, was fehlt. git-git stellt beschädigten Blob wieder her

Aber am Ende hatte ich lose / beschädigte Baumobjekte, die durch einen teilweisen Festplattenfehler verursacht wurden, und Baumobjekte sind nicht so einfach wiederherzustellen / werden von diesem Dokument nicht abgedeckt.

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

Ich hatte immer noch viele baumelnde Blobs, die ein Nebeneffekt beim Auspacken zuvor archivierter Inhalte sein können und in anderen Fragen hier angesprochen wurden

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  

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 Ihre beschädigte Datei zunächst 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 dies anders 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!

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

Die Nachrichten sahen folgendermaßen 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 versucht, git fsckaber das hat nicht geholfen. Da der Absturz während eines git pushaufgetreten ist, ist er offensichtlich während des Umschreibens auf der Clientseite aufgetreten, das nach der Aktualisierung des Servers auftritt. Ich sah mich um und stellte fest, dass es sich c2388in meinem Fall um ein Commit-Objekt handelte, auf das durch Einträge in verwiesen wurde .git/refs. Ich wusste also, dass ich es finden würde, c2388wenn ich mir den Verlauf anschaue (über ein Webinterface oder einen zweiten Klon).

Beim zweiten Klon habe ich a gemacht git log -n 2 c2388, um den Vorgänger von zu identifizieren c2388. Dann habe ich manuell geändert .git/refs/heads/masterund .git/refs/remotes/origin/masterder Vorgänger von c2388statt zu sein c2388. Dann könnte ich eine machen git fetch. Das ist git fetcheinige Male bei Konflikten mit leeren Objekten fehlgeschlagen. Ich habe jedes dieser leeren Objekte entfernt, bis es git fetcherfolgreich war. Das hat das Repository geheilt.

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

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

Ich hatte gerade ein Problem wie dieses. Mein besonderes Problem wurde durch einen Systemabsturz verursacht, der das letzte Commit (und damit auch den Hauptzweig) beschädigte. Ich hatte nicht gepusht und wollte dieses Commit erneut machen. In meinem speziellen Fall konnte ich so damit umgehen:

1. Erstellen Sie ein Backup von .git/:rsync -a .git/ git-bak/
2. Überprüfen Sie .git/logs/HEADund finden Sie die letzte Zeile mit einer gültigen Festschreibungs-ID. Für mich war dies das zweitletzte Commit. Das war gut, denn ich hatte immer noch die Arbeitsverzeichnisversionen der Datei und damit jede Version, die ich wollte.
3. Machen Sie eine Verzweigung bei diesem Commit: git branch temp <commit-id>
4. Führen Sie das fehlerhafte Commit mit den Dateien im Arbeitsverzeichnis erneut aus.
5. git reset master temp um den Hauptzweig auf das neue Commit zu verschieben, das Sie in Schritt 2 vorgenommen haben.
6. git checkout masterund überprüfen Sie, ob es richtig aussieht git log.
7. git branch -d temp.
8. git fsck --fullund es sollte jetzt sicher sein, beschädigte Objekte zu löschen, die fsck findet.
9. Wenn alles gut aussieht, versuchen Sie es. Wenn das geht,

Das hat bei mir funktioniert. Ich vermute, dass dies ein recht häufiges Szenario ist, da das letzte Commit am wahrscheinlichsten beschädigt ist. Wenn Sie jedoch ein weiteres Commit verlieren, können Sie wahrscheinlich immer noch eine Methode wie diese verwenden, bei sorgfältiger Verwendung git cherrypickund Reflog in .git/logs/HEAD.

Als ich dieses Problem hatte, habe ich meine letzten Änderungen gesichert (da ich wusste, was ich geändert hatte) und dann die Datei gelöscht, über die ich mich in .git / location beschwert habe. Dann habe ich einen Git Pull gemacht. Seien Sie jedoch vorsichtig, dies funktioniert möglicherweise nicht für Sie.

Ich bin darauf gestoßen, als mein System abstürzte. Was ich getan habe ist folgendes:

(Bitte beachten Sie, dass Ihre beschädigten Commits verloren gehen, die Änderungen jedoch beibehalten werden. Möglicherweise müssen Sie diese Commits am Ende dieses Vorgangs neu erstellen.)

• Sichern Sie Ihren Code.
• Gehen Sie in Ihr Arbeitsverzeichnis und löschen Sie den .gitOrdner.
• Klonen Sie nun die Fernbedienung an einem anderen Ort und kopieren Sie den .gitOrdner darin.
• Fügen Sie es in Ihr Arbeitsverzeichnis ein.
• Commit wie du wolltest.

Entfernen Sie einfach den Ordner .git und fügen Sie ihn erneut hinzu. Diese einfache Lösung hat bei mir funktioniert.