Git: "Loses Objekt beschädigen"

329

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?

Asgerhallas
quelle
Haben Sie versucht, das letztere Objekt zu betrachten (45ba4ceb93bc812ef20a6630bb27e9e0b33a012a)?
Gintautas Miliauskas
4
Danke ... aber wie "schaut" man ein Objekt an? Noch neu bei Git :)
Asgerhallas
2
"Git Show" gibt mir leider nichts mehr als "Git Fsck" schon.
Asgerhallas
4
Linus Torvalds hat das folgende hilfreiche Dokument über diesen Fehler und das manuelle Rekonstruieren der Blobs geschrieben, wenn Sie über die Dateien verfügen: Wiederherstellen eines beschädigten Blob-Objekts Einige Tricks zum Rekonstruieren von Blob-Objekten, um ein beschädigtes Repository zu reparieren
Uwe Kleine-König
2
Können Sie einige Kommentare hinzufügen oder die akzeptierte Antwort bearbeiten? Ich bin in genau der gleichen Situation und die akzeptierte Antwort scheint nicht genug Details zu "Just Work TM" zu enthalten, sondern zwingt mich stattdessen, selbst in die Details einzutauchen.
Ripper234

Antworten:

57

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.

Adam Dymitruk
quelle
2
Es kann in einer Pack-Datei gespeichert werden. Auf diese Weise komprimiert Git die Speicherung von Objekten durch Speichern von Deltas. Lose Objekte befinden sich noch nicht in einem Paket. Google für Pack-Dateien, Index-Dateien in Git und Sie sollten in der Lage sein, so tief wie nötig einzutauchen.
Adam Dymitruk
2
Könnten Sie in Ihrer Antwort einen Link zu Chacons Git-Screencasts angeben?
Ehtesh Choudhury
1
git cat-file -t <SHA1>wird Ihnen den Typ sagen. Wenn nicht beschädigt, können Sie dann tun git cat-file <type> <SHA1>, um den Inhalt zu sehen (ich habe es für eine verwendet blob, ich denke, es wird Ihnen auch den Inhalt anderer Typen zeigen.)
Carl G
1
Auch dieser Beitrag von Linus beschreibt den Prozess zum Wiederherstellen von a blob. Als ich diesen Anweisungen folgte, git statusantwortete fatal: unable to read <SHA1>ich, obwohl ich erfolgreich ausgeführt hatte git hash-object -w <file>(wahrscheinlich, weil ich diese Objektdatei gemäß seinen Anweisungen weggeschoben hatte. Die Rückgabe gab mir nur den gleichen corrupt loose objectFehler.)
Carl G
2
Und jetzt bitte auf Englisch wiederholen
Mehdi
359

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 [email protected]: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.

kubischer Salat
quelle
11
Diese Methode hat bei mir funktioniert. Ich glaube jedoch, dass alle nicht gepolsterten Commits verloren gegangen sind. Repo-Daten blieben unberührt.
Wonton
30
Ja, nicht gepumpte Commit-Informationen gehen verloren. In gängigen Szenarien (keine mehreren lokalen Zweige mit nicht gepushten Änderungen in anderen als den aktuellen) befinden sich jedoch alle neuesten Dateimodifikationen (inkl. Löschungen) immer noch auf der Festplatte, sodass frühere nicht gepusste Commits problemlos wiederholt werden können. Da ich immer nach einer Abfolge von Commits pushe, bin ich nicht einmal auf diese Probleme gestoßen.
kubischer Salat
7
Einfach und unkompliziert. Dies ist, IMO, die effizienteste Lösung, wenn Sie nicht alles über Git verstehen und nicht mit Ihrem Repository herumspielen möchten.
Oliboy50
4
Ich denke, es würde alle Verstecke entfernen, da sie im Unterverzeichnis .git gespeichert sind.
Anthony Elliott
4
Falls das Projekt Submodule enthält, müssen diese vor dem Abrufen des .gitOrdners initiiert werden .
AdrieanKhisbe
240

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.

user1055643
quelle
12
IMHO sollte dies die akzeptierte Antwort sein. Viel einfacher als das Repo zu löschen und neu zu klonen! :) Obwohl Sie keine inszenierten Commits verlieren ...
Nick
6
Wenn Sie sich zum Zeitpunkt der Beschädigung in einer anderen Filiale als dem Master befanden, ersetzen Sie diese natürlich durch masterIhren Filialnamen.
Timothy Zorn
Meistens funktionierte es so wie es ist, aber ich war in einem anderen Zweig, workingals es beschädigt war, und diese Schritte gaben mir keine lokale Kopie eines anderen Zweigs als Master (und ja, ich hatte versucht, Master oben durch zu ersetzen, workingaber das funktionierte nicht). Am Ende habe ich die obigen Schritte mit ausgeführt master, dann meine Änderungen verstaut checkout -b working origin/workingund das Versteck dort abgelegt . Scheint funktioniert zu haben - danke!
fantastisch
1
Mein Repository hatte ein Submodul, das nicht beschädigt war. Dieser Prozess ließ die Repository- und seine Submodul in einem Zustand , in dem Befehle wie git statusergab fatal: Not a git repository: submodules/my-sub/../../.git/modules/my-sub. Durch Löschen des Submoduls aus dem Dateisystem und Neustarten des Prozesses wurde die Normalität wiederhergestellt. Wahrscheinlich ist es eine gute Idee, zuerst sicherzustellen, dass es keine ungeschobenen Änderungssätze in Submodulen gibt ...
Steven Baldasty
5
Ich habe dies heute getan und nicht unverbindliche Änderungen an den Dateien verloren :) (git 2.17.1)
Fábio Dias
172

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.

Felipe Pereira
quelle
10
find .git/objects/ -size 0 -exec rm -f {} \;arbeitet für mich;)
Lazaro Fernandes Lima Suleiman
Hatte das gleiche Problem, führte den Befehl aus, funktionierte perfekt für mich auf Mint VM.
Ludvig Rydahl
Funktionierte auch perfekt, ohne etwas anderes tun zu müssen.
Halsafar
1
Nicht auf einer VM und das hat bei mir schon oft funktioniert. IDK, warum dies in meinem aktuellen Projekt immer wieder passiert, aber dies behebt es jedes Mal.
James L.
7
Möglicherweise müssen Sie git symbolic-ref HEAD refs/heads/master.nach dem Löschen der leeren Objekte ausgeführt werden.
Stephan
43

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.

deklarieren
quelle
Ich befand mich in einer Situation, in der ich keine Remote- oder Sicherungskopie meines Repos hatte und das beschädigte Objekt in der Nähe des anfänglichen Commits hinzugefügt wurde, wodurch wahrscheinlich der gesamte Baum ohnehin beschädigt wurde. Ich habe auf meine eigene Weise versucht, das Objekt in einem anderen Repo neu zu erstellen, aber diese Antwort erzielt das gleiche Ergebnis mit mehr Finesse.
Estecka
13

Versuchen

git stash

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

Arthur
quelle
Seltsam!?! Ist heute Morgen auf diesen Fehler gestoßen. Hatte gestern zugesagt, also nichts Ungebundenes geändert. Hat die folgenden: git stash ... fatal: Kann nicht '/home/<user>/.git/index.lock' erstellen: Ein- / Ausgabefehler touch .git/a touch: nicht berühren '.git / a': Ein- / Ausgabefehler sudo touch /home/guest/.git/a NO ERROR git stash Nein lokale Änderungen zu speichern git status ... nichts zu
festschreiben
1
@ go2null Ich bin etwas spät dran, aber Eingabe- / Ausgabefehler bedeuten im Allgemeinen Festplattenprobleme. Obwohl ich sicher bin, dass Sie das inzwischen herausgefunden haben.
Arleslie
"Der aktuelle Indexstatus kann nicht gespeichert werden"
Vladimir Brasil,
9

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.

Jago
quelle
Das ist eine gute Lösung. Hat für mich gearbeitet. Mein System wurde versehentlich heruntergefahren. Dieser eine Befehl rettete mich jedoch vor dem Klonen und all diesen schweren Aufgaben. Danke Jago.
Mukesh Kumar
"Reflog konnte nicht ausgeführt werden"
Vladimir Brasil
5

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

Tyler Gauch
quelle
Dies hat bei mir funktioniert und scheint die einfachste Lösung zu sein. Ich bin mir nicht sicher, warum diese Antwort nicht mehr Stimmen erhielt. Der einzige Nachteil ist, dass der nächste git pulletwas länger dauert als gewöhnlich, weil er einige entfernte Objekte oder ähnliches ersetzt.
steev
1
Der Grund könnte sein, dass Git Prune das Problem überhaupt nicht löst.
user3072843
4

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 [email protected]: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.

halfer
quelle
3

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.

Rebecca Dessonville
quelle
2

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.

Dean Rather
quelle
2

Runnning hat git stash; git stash popmein Problem behoben

Simonluca Landi
quelle
2

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

davenpcj
quelle
2

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  
Ertuğrul Altınboğa
quelle
ist --set-upstream-to ein gültiges Argument? Das glaube ich nicht!
Sharif Mamun
2
Git Branch (--set-upstream-to = <upstream> | -u <upstream>) [<branchname>]
Ertuğrul Altınboğa
Wenn Sie .gitdas geklonte Projekt entfernen und daraus kopieren, funktioniert Repo, es werden jedoch weder lokale Zweige noch Verstecke beibehalten.
Vladimir Vukanac
1

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!

Thomas Lobjoie
quelle
1

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.

Christian Hujer
quelle
1

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.)

mcginn
quelle
0

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.

konyak
quelle
0

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.

naught101
quelle
0

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.

gareth
quelle
0

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.
Wajahath
quelle
-7

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

Ovidiu Matan
quelle
3
Dies wird Ihr lokales Repository zerstören ... könnte eher unerwünschte Nebenwirkungen haben :) Bitte bearbeiten Sie Ihren Vorschlag und fügen Sie diese Warnung hinzu.
Felix
1
Wenn Sie .gitdas Clonn-Projekt entfernen und daraus kopieren, funktioniert Repo, es werden jedoch weder lokale Zweige noch Verstecke beibehalten. Auch ein freundlicher Vorschlag, löschen Sie Ihre Antwort vollständig, um keine Down-Votes mehr zu erhalten.
Vladimir Vukanac
1
whoa nelly ... rede über die Verwendung einer Panzerfaust für einen Pinzettenjob.
Tuncay Göncüoğlu