Wie behebe ich den GIT-Fehler: Die Objektdatei ist leer?

Wenn ich versuche, Änderungen festzuschreiben, wird folgende Fehlermeldung angezeigt:

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

Irgendeine Idee, wie man diesen Fehler löst?

BEARBEITEN

Ich habe versucht, git fsckich habe:

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

Ich hatte ein ähnliches Problem. Mein Laptop hat während einer Git-Operation keinen Akku mehr. Boo.

Ich hatte keine Backups. (Hinweis: Ubuntu One ist keine Backup-Lösung für Git. Es überschreibt Ihr vernünftiges Repository hilfreich mit Ihrem beschädigten.)

Wenn dies ein schlechter Weg war, um das Problem zu beheben, hinterlassen Sie bitte einen Kommentar. Es hat jedoch bei mir funktioniert ... zumindest vorübergehend.

Schritt 1: Erstellen Sie eine Sicherungskopie von .git (tatsächlich mache ich dies zwischen jedem Schritt, der etwas ändert, aber mit einem neuen Copy-to-Namen, z. B. .git-old-1, .git-old-2 usw.) ::

cp -a .git .git-old

Schritt 2: Ausführen git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Schritt 3: Entfernen Sie die leere Datei. Ich dachte mir was zum Teufel; es ist sowieso leer.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Schritt 3: Führen Sie git fsckerneut aus. Löschen Sie weiterhin die leeren Dateien. Sie können auch cdin das .gitVerzeichnis gehen und ausführen find . -type f -empty -delete -print, um alle leeren Dateien zu entfernen. Irgendwann sagte mir Git, dass es tatsächlich etwas mit den Objektverzeichnissen zu tun habe:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Schritt 4: Nachdem ich alle leeren Dateien gelöscht hatte, wurde ich schließlich git fscktatsächlich ausgeführt:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Schritt 5: Versuchen Sie es git reflog. Scheitern Sie, weil mein KOPF gebrochen ist.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Schritt 6: Google. Finde das . Holen Sie sich manuell die letzten beiden Zeilen des Reflogs:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <[email protected]> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <[email protected]> 1347358589 -0400  commit: fixed up to page 28

Schritt 7: Beachten Sie, dass wir aus Schritt 6 erfahren haben, dass der HEAD derzeit auf das allerletzte Commit zeigt. Versuchen wir also, nur das übergeordnete Commit zu betrachten:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Es funktionierte!

Schritt 8: Jetzt müssen wir HEAD auf 9f0abf890b113a287e10d56b66dbab66adc1662d zeigen.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Welches hat sich nicht beschwert.

Schritt 9: Sehen Sie, was fsck sagt:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Schritt 10: Der ungültige sha1-Zeiger im Cache-Baum schien aus einer (jetzt veralteten) Indexdatei ( Quelle ) zu stammen. Also habe ich es getötet und das Repo zurückgesetzt.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Schritt 11: Nochmals auf den fsck schauen ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

Die baumelnden Blobs sind keine Fehler . Ich beschäftige mich nicht mit master.u1conflict, und jetzt, wo es funktioniert, möchte ich es nicht mehr anfassen!

Schritt 12: Auf dem Laufenden bleiben mit meinen lokalen Änderungen:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Hoffentlich kann das den Menschen in Zukunft von Nutzen sein. Ich bin froh, dass es funktioniert hat.

Die Git-Objektdateien sind beschädigt (wie auch in anderen Antworten erwähnt). Dies kann bei Maschinenabstürzen usw. passieren.

Ich hatte das gleiche. Nachdem ich die anderen Top-Antworten hier gelesen hatte, fand ich den schnellsten Weg, um das kaputte Git-Repository mit den folgenden Befehlen zu reparieren (im Git-Arbeitsverzeichnis ausführen, das den .gitOrdner enthält ):

(Stellen Sie sicher, dass Sie zuerst Ihren Git-Repository-Ordner sichern!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Dadurch werden zuerst alle leeren Objektdateien entfernt , die eine Beschädigung des gesamten Repositorys verursachen. Anschließend werden die fehlenden Objekte (sowie die letzten Änderungen) aus dem Remote-Repository abgerufen und anschließend eine vollständige Objektspeicherprüfung durchgeführt . Was an dieser Stelle ohne Fehler gelingen sollte (es kann jedoch noch einige Warnungen geben!)

PS. Diese Antwort deutet darauf hin, dass Sie irgendwo eine Remote-Kopie Ihres Git-Repositorys haben (z. B. auf GitHub) und das defekte Repository das lokale Repository ist, das an das Remote-Repository gebunden ist, das noch in Kontakt ist. Wenn dies nicht der Fall ist, versuchen Sie nicht, das Problem so zu beheben, wie ich es empfehle.

Dieser Fehler tritt auf, wenn ich mein Commit drücke und mein Computer hängt. So habe ich es behoben.

Schritte zu beheben

git status

Zeigen Sie die leere / beschädigte Objektdatei an

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

entfernen Sie es

git status

Ich habe eine fatal: bad object HEADNachricht erhalten

rm .git/index

Ich entferne das indexfür den Reset

git reset

fatal: Objekt 'HEAD' konnte nicht analysiert werden.

git status
git pull

nur um zu überprüfen, was passiert

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

druckt die letzten 2 Zeilen tail -n 2des Protokollzweigs, um meine letzten 2 anzuzeigencommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Ich wähle den letzten aus commit hash

git status

zeigt alle meine Dateien als deletedweil ich die .git/indexDatei entfernt habe

git reset

Fahren Sie mit dem Zurücksetzen fort

git status

Überprüfen Sie mein Update

Hinweis: Die Schritte beginnen, wenn ich auf dieser Frage gelandet bin und die Antworten als Referenz verwendet habe.

Ich habe dieses Problem gelöst, indem ich die verschiedenen leeren Dateien entfernt habe, die git fsck erkannt hat, und dann einen einfachen git pull ausgeführt habe.

Ich finde es enttäuschend, dass jetzt, da sogar Dateisysteme Journaling und andere "Transaktions" -Techniken implementieren, um das fs gesund zu halten, git aufgrund eines Stromausfalls oder eines Speicherplatzes auf dem Gerät in einen beschädigten Zustand geraten kann (und nicht in der Lage ist, sich selbst wiederherzustellen).

Ich hatte nur das gleiche Problem: Nachdem ich das entfernte Repository abgerufen hatte, bekam ich beim Ausführen eines Git-Status Folgendes: "Fehler: Objektdatei (...) ist leer" "fatal: loses Objekt (...) ist beschädigt"

Die Art und Weise, wie ich das gelöst habe, war:

1. git stash
2. Entfernen der Git-Datei im Fehlerfall (nicht sicher, ob dies erforderlich ist)
3. git stash klar

Ich weiß nicht genau, was passiert ist, aber diese Anweisungen schienen alles sauber zu machen.

Da ich meine VM regelmäßig neu starten muss, passiert mir dieses Problem irgendwie sehr oft. Nach einigen Malen wurde mir klar, dass ich den von @ Nathan-Vanhoudnos beschriebenen Vorgang nicht jedes Mal wiederholen kann, obwohl dies immer funktioniert. Dann fand ich die folgende schnellere Lösung heraus.

Schritt 1

Verschieben Sie Ihr gesamtes Repo in einen anderen Ordner.

mv current_repo temp_repo

Schritt 2

Klonen Sie das Repo erneut vom Ursprung.

git clone source_to_current_repo.git

Schritt 3

Entfernen Sie alles unter dem neuen Repo außer dem Ordner .git .

Schritt 4

Bewegen Alles vom temp_repo zum neuen Repo außer dem .git Ordner.

Schritt 5

Entfernen Sie das temp_repo und wir sind fertig.

Ich bin mir sicher, dass Sie diese Prozeduren nach einigen Malen sehr schnell ausführen können.

1. mv Ihre Ordner-App, um ein Backup zu erstellen , dh mv app_folder app_folder_bk (es ist wie ein Git-Stash )
2. git klone dein_repository
3. Schließlich,. Öffnen Sie ein Zusammenführungstool (ich verwende Meld Diff Viewer Linux oder Winmerge Windows) und kopieren Sie die Änderungen von rechts ( app_folder_bk ) nach links (neuer app_folder ) (es ist wie ein Git Stash Apply ).

Das ist alles. Vielleicht ist es nicht der beste Weg, aber ich denke, es ist so praktisch.

In meinem Fall ist dieser Fehler aufgetreten, weil ich die Festschreibungsnachricht eingegeben und mein Notizbuch ausgeschaltet habe.

Ich habe die folgenden Schritte ausgeführt, um den Fehler zu beheben:

• git checkout -b backup-branch # Erstellen Sie einen Sicherungszweig
• git reset --hard HEAD~4# Auf das Commit zurücksetzen, wo alles gut funktioniert. In meinem Fall musste ich 4 Commits im Kopf sichern, dh bis mein Kopf an dem Punkt war, an dem ich die Commit-Nachricht eingegeben hatte. Bevor Sie diesen Schritt ausführen, kopieren Sie den Hash der Commits, die Sie zurücksetzen möchten. In meinem Fall habe ich den Hash der 4 letzten Commits kopiert
• git cherry-pick <commit-hash> # Cherry wählt die zurückgesetzten Commits (in meinem Fall 4 Commits, also habe ich diesen Schritt 4 Mal ausgeführt) aus dem alten Zweig in den neuen Zweig.
• git push origin backup-branch # Schieben Sie den neuen Zweig, um sicherzustellen, dass alles gut funktioniert
• git branch -D your-branch # Löschen Sie den Zweig lokal ('Ihr Zweig' ist der Zweig mit dem Problem)
• git push origin :your-branch # Löschen Sie den Zweig von der Fernbedienung
• git branch -m backup-branch your-branch # Benennen Sie den Sicherungszweig um, um den Namen des Zweigs zu erhalten, bei dem das Problem aufgetreten ist
• git push origin your-branch # Schieben Sie den neuen Zweig
• git push origin :backup-branch # Löschen Sie den Sicherungszweig von der Fernbedienung

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

Löse mein Problem

Hier ist eine wirklich einfache und schnelle Art und Weise mit diesem Problem umgehen IF Sie einen lokalen Repo mit allen Zweigen haben und verpflichtet Sie brauchen, und wenn Sie OK mit einer neuen Repo - Erstellung (oder Löschen des Repo - Server und macht eine neue an seinem Platz):

1. Erstellen Sie ein neues leeres Repo auf dem Server (oder löschen Sie das alte Repo und erstellen Sie an seiner Stelle ein neues)
2. Ändern Sie die Remote-URL Ihrer lokalen Kopie so, dass sie auf die Remote-URL des neuen Repos verweist.
3. Verschieben Sie alle Zweige von Ihrem lokalen Repo auf das neue Server-Repo.

Dadurch bleiben alle Commit-Historien und Zweige erhalten, die Sie in Ihrem lokalen Repo hatten.

Wenn Sie Mitarbeiter im Repo haben, müssen Ihre Mitarbeiter in vielen Fällen nur die Remote-URL ihres lokalen Repos ändern und optional alle Commits übertragen, die der Server nicht hat.

Diese Lösung hat bei mir funktioniert, als ich auf dasselbe Problem gestoßen bin. Ich hatte einen Mitarbeiter. Nachdem ich mein lokales Repo auf das neue Remote-Repo verschoben hatte, änderte er einfach sein lokales Repo, um auf die Remote-Repo-URL zu verweisen, und alles funktionierte einwandfrei.

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 vermeiden, ein großes Repository zu löschen und neu zu klonen. Wenn Sie wichtige lokale Änderungen haben, sollten Sie 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 einige beschädigte Objektdateien, die beim Aufrufen jeweils nur einzeln angezeigt git fsck --fullwurden. Deshalb habe ich einen kleinen Shell-Einzeiler geschrieben, um eine davon 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 an stdout weiter, um sie abrufen zu können
• verwendete grep-Optionen:
  • -o Gibt nur den Teil einer Zeile zurück, der tatsächlich übereinstimmt
  • -E aktiviert erweiterte reguläre Ausdrücke
  • -m 1 Stellen Sie sicher, dass nur die erste Übereinstimmung zurückgegeben wird
  • [0-9a-f]{2} stimmt mit einem der Zeichen zwischen 0 und 9 und a und f überein, wenn zwei von ihnen zusammen vorkommen
  • [0-9a-f]* Entspricht einer beliebigen Anzahl von Zeichen zwischen 0 und 9 und a und f, die zusammen vorkommen

Es wird immer noch jeweils nur eine Datei gelöscht. Sie können sie daher in einer Schleife wie folgt aufrufen:

$ 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 es nichts Nützliches mehr ausgibt, sodass Sie nicht wissen, wann es fertig ist (es sollte nach einiger Zeit einfach nichts Nützliches mehr tun).

Um dies zu "beheben", habe ich dann git fsck --fullnach jeder Runde wie folgt einen Aufruf hinzugefügt : $ 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

Es ist jetzt ungefähr halb so schnell, aber es gibt seinen "Zustand" aus.

Danach habe ich einige mit den Vorschlägen in diesem Thread herumgespielt und bin schließlich an einen Punkt gekommen, an dem ich konnte git stashund git stash dropviele der kaputten Sachen.

erstes Problem gelöst

Danach hatte ich noch folgendes Problem: unable to resolve reference 'refs/remotes/origin/$branch': reference brokendas konnte durch gelöst werden $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

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

$ git remote prune origin

für ein gutes Maß und

git reflog expire --stale-fix --all

error: HEAD: invalid reflog entry $blubbbeim Laufen loswerden git fsck --full.

Lassen Sie uns einfach gehen. Nur für den Fall, dass Sie die Quelle auf Remote Git Repo hochgeladen haben

1. Sichern Sie Ihre .git

2. Überprüfe deinen Git

   git fsck --full
   

3. leere Objektdatei entfernen (alle)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. Überprüfe deinen Git noch einmal.

   git fsck --full
   

5. Ziehen Sie Ihre Quelle von Remote Git

   git pull origin master
   

Bei virtuellen Maschinen stoße ich häufig auf dieses Problem.

Für mich funktioniert folgendes:

cd /path/to/your/project
rm -rf .git

Wenn Sie sich einige Downloads sparen möchten, gehen Sie in Ihren Datei-Explorer und löschen Sie alle Dateien in dem Ordner, die bereits festgeschrieben sind, und belassen Sie sie in Ihren Ordnern / vendor und / node_modules (ich arbeite mit Composer und npm).

dann erstelle einfach ein neues repo

git init

Fügen Sie Ihre Fernbedienung hinzu

git remote add origin ssh://[email protected]/YourUsername/repoName.git

und holen Sie den Zweig / alles davon

git fetch origin somebranch

und schau es dir an

git checkout somebranch

dann sollten Sie an der Stelle vor dem Fehler sein.

Hoffe das hilft.

Grüße.

Ich habe das gleiche Problem und benutze eine sehr einfache Methode, um es zu beheben. Ich fand heraus, dass diese fehlenden Dateien auf dem Computer meines Teamkollegen vorhanden waren.

Ich habe diese Dateien einzeln auf einen Git-Server kopiert (insgesamt 9 Dateien), und das hat das Problem behoben.

Meine Kollegen und ich haben dieses Problem mehrmals gekreuzt. 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 Datenverlust.

1. Benennen Sie das aktuelle Arbeitsverzeichnis um. ( old_projectfür dieses Beispiel).
2. Klonen Sie das Repository in ein neues Verzeichnis mit git clone.
3. Ändern Sie in der Befehlszeile das Arbeitsverzeichnis in das neu erstellte Projekt und wechseln Sie zu dem Zweig, an dem Sie gearbeitet haben.
4. Kopieren Sie alle Dateien und Verzeichnisse old_project(außer dem .gitVerzeichnis) in das neu erstellte Projektverzeichnis.
5. Überprüfen Sie Ihren Arbeitsbaumstatus (beachten Sie, dass es viel mehr Änderungen gibt als erwartet) und übernehmen Sie die Änderungen.

Ich hoffe, es hilft...

Hier ist eine Möglichkeit, das Problem zu lösen, wenn Ihr öffentliches Repo auf github.com funktioniert, Ihr lokales Repo jedoch beschädigt ist. Beachten Sie, dass Sie alle Commits verlieren, die Sie im lokalen Repo ausgeführt haben.

Okay, ich habe also ein Repo vor Ort, das mir dies gibt object empty error, und dasselbe Repo auf github.com, aber ohne diesen Fehler. Also habe ich einfach das Repo, das von Github funktioniert, geklont und dann alles aus dem beschädigten Repo (außer dem Ordner .git) kopiert und das geklonte Repo, das funktioniert, eingefügt.

Dies ist möglicherweise keine praktische Lösung (da Sie die lokalen Commits löschen). Sie behalten jedoch den Code und eine reparierte Versionskontrolle bei.

Denken Sie daran, ein Backup zu erstellen, bevor Sie diesen Ansatz anwenden.

In meinem Fall war es für mich nicht wichtig, den lokalen Commit-Verlauf beizubehalten. Wenn dies auch für Sie gilt, können Sie dies als schnelle Alternative zu den oben genannten Lösungen tun:

Sie ersetzen einfach das beschädigte .git/Verzeichnis durch ein sauberes.

Nehmen wir das folgende Verzeichnis für Ihr Projekt mit dem beschädigten Git an: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (optional) Backup erstellen
2. git clone [repo URL] projects/clean_git - damit du bekommst projects/clean_git
3. rm -rf corrupt_git/.git/ - Entfernen Sie den beschädigten .git-Ordner
4. mv clean_git/.git/ corrupt_git/ - Sauberes Git nach bewegen corrupt_git/.git
5. git statusin projects/corrupt_git- um sicherzustellen, dass es funktioniert

Kopieren Sie alles (in dem Ordner, der die .git enthält) in eine Sicherung, löschen Sie dann alles und starten Sie neu. Stellen Sie sicher, dass Sie die Git-Fernbedienung zur Hand haben:

git remote -v
 origin [email protected]:rwldrn/idiomatic.js.git (fetch)
 origin [email protected]:rwldrn/idiomatic.js.git (push)

Dann

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin [email protected]:rwldrn/idiomatic.js.git

Führen Sie dann alle neuen Dateien manuell zusammen und versuchen Sie, Ihren Computer eingeschaltet zu lassen.

Hatte das gleiche Problem nach dem Auschecken des Masters aus einem sauberen Zweig. Nach einer Weile erkannte ich viele geänderte Dateien im Master. Ich weiß nicht, warum sie dort waren, nachdem sie von einer sauberen Filiale gewechselt sind. Wie auch immer, da die geänderten Dateien für mich keinen Sinn machten, habe ich sie einfach verstaut und der Fehler war verschwunden.

git:(master) git stash

Wenn Sie ein ALTES Backup haben und es eilig haben:

Erstellen Sie eine NEUE SICHERUNG Ihres aktuellen Projektpfads.

1. Verschiebe deinen .gitin den Papierkorb (niemals löschen)
2. Kopie .gitaus dem ALTEN Backup
3. git pull (führt zu Zusammenführungskonflikten)
4. Verschiebe alle deine Quellen (alles, was du in Git steckst) in den Papierkorb: ./src (niemals löschen)
5. Kopieren Sie alle Ihre Quellen (alles, was Sie in git eingegeben haben) aus dem NEUEN BACKUP
6. Akzeptiere alle "Zusammenführungen" git gui, drücke und ... klatsche in die Hände!

Die oben beschriebene zwölfstufige Lösung hat mir auch geholfen, aus einem Stau herauszukommen. Vielen Dank. Die wichtigsten Schritte waren:

git fsck --full 

und entfernen Sie alle leeren Objekte

rm .git/objects/...

Dann bekommen Sie die zwei Zeilen der Peitsche:

tail -n 2 .git/logs/refs/heads/master

Mit den zurückgegebenen Werten

git update-ref HEAD ...

Zu diesem Zeitpunkt hatte ich keine Fehler mehr, daher habe ich eine Sicherungskopie meiner neuesten Dateien erstellt. Dann machen Sie einen Git-Pull, gefolgt von einem Git-Push. Kopierte meine Backups in meine Git-Repository-Datei und führte einen weiteren Git-Push durch. Das hat mich auf den neuesten Stand gebracht.

Ich habe meinen Git-Fehler behoben: Die Objektdatei ist leer durch:

1. Speichern einer Kopie aller Dateien, die ich seit meinem letzten erfolgreichen Commit / Push bearbeitet habe.
2. Entfernen und erneutes Klonen meines Repositorys,
3. Ersetzen der alten Dateien durch meine bearbeiteten Dateien.

Hoffe das hilft.

Das passiert mir auch fast regelmäßig. Ich habe kein Protokoll erstellt, wenn dies genau passiert, aber ich habe den Verdacht, dass es auftritt, wenn meine virtuelle Maschine "unerwartet" existiert. Wenn ich das VM-Fenster schließe (ich verwende Ubuntu 18.04) und erneut starte, funktionieren die Dinge immer (?). Wenn das VM-Fenster jedoch beim Herunterfahren meines Laptops (Windows-Hostsystem) noch geöffnet ist, tritt dieses Problem häufig auf.

Zu allen hier gegebenen Antworten:

1. danke - sie sind sehr nützlich; Normalerweise speichere ich eine lokale Kopie meines Codes, stelle das Repo von der Fernbedienung wieder her und verschiebe die Sicherungskopie zurück in den lokalen Ordner.

2. Da das zugrunde liegende Problem nicht wirklich ein Git-Problem ist, sondern ein VM- und / oder Linux-Problem, frage ich mich, ob es keinen Weg geben sollte, den Grund und nicht die Symptome zu heilen. Zeigt diese Art von Fehler nicht an, dass einige Dateisystemänderungen nicht in angemessener Zeit "angewendet", sondern nur zwischengespeichert werden? (Siehe zum Beispiel /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - Für mich scheint es, als ob virtuelle Linux-Maschinen dies nicht tun fsynch ihre Sachen häufig genug. Ob dies ein Problem der VirtualBox von Oracle (das ansonsten sehr gut funktioniert) oder des Gastdateisystems oder einiger Einstellungen ist, die wir alle übersehen, liegt außerhalb meines Fachwissens. Aber ich würde mich freuen, wenn jemand Licht ins Dunkel bringen könnte.

Eigentlich hatte ich das gleiche Problem. Haben Sie eine Kopie Ihres Codes, bevor Sie dies versuchen.

Ich habe es gerade getan git reset HEAD~

Mein letztes Commit wurde rückgängig gemacht, dann habe ich es erneut festgeschrieben, Problem gelöst!

Warnung: Mit mehr Erfahrung wird mir klar, dass dies die nukleare Option ist und normalerweise nicht durchgeführt werden sollte und nichts lehrt. In seltenen Fällen für persönliche Projekte fand ich es jedoch immer noch nützlich, also lasse ich es offen.

Wenn Sie Ihre historischen Verpflichtungen nicht einhalten möchten, führen Sie sie einfach aus

rm -r .git

Beantworten Sie dann alle Fragen zum Löschen schreibgeschützter Dateien mit Ja. Problem in weniger als einer Minute gelöst.