Wie kann ich den Git-Fehler "Objektdatei ... ist leer" beheben?

Question

Wenn ich versuche, Änderungen zu übertragen, erhalte ich diesen Fehler:

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

Ich habe versucht git fsck Das habe ich:

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

Wie kann ich diesen Fehler beheben?

Answer 1

Ich hatte ein ähnliches Problem. Meinem Laptop ging während einer Git-Operation der Akku aus. Buh.

Ich hatte keine Sicherungskopien. (N.B. Ubuntu One ist keine Backup-Lösung für Git; es überschreibt hilfsweise Ihr intaktes Repository mit Ihrem beschädigten).

An die Git-Assistenten: Wenn dies ein schlechter Weg war, es zu beheben, bitte einen Kommentar hinterlassen. Bei mir hat es jedoch funktioniert... zumindest vorübergehend.

Schritt 1: Erstellen Sie ein Backup des Ordners .git (Tatsächlich mache ich das zwischen jedem Schritt, der etwas ändert, aber mit einem neuen copy-to Namen, z.B., .git-old-1 , .git-old-2 , usw.):

cd ~/workspace/mcmc-chapter
cp -a .git .git-old

Schritt 2: Ausführen git fsck --full

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 soll's, sie ist sowieso leer.

rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e

rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Schritt 3: Ausführen git fsck wieder. Fahren Sie fort, die leeren Dateien zu löschen. Sie können auch cd in die .git Verzeichnis und führen Sie find . -type f -empty -delete -print um alle leeren Dateien zu entfernen. Schließlich begann Git mir zu sagen, dass es tatsächlich etwas mit den Objektverzeichnissen macht:

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, kam ich schließlich zu git fsck tatsächlich läuft:

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: Versuch git reflog . Scheitern, weil mein KOPF kaputt ist.

git reflog

fatal: bad object HEAD

Schritt 6: Google. finden. este . Holen Sie sich manuell die letzten beiden Zeilen des Reflogs:

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

f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <nathanvan@gmail.com> 1347306977 -0400    commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <nathanvan@gmail.com> 1347358589 -0400    commit: fixed up to page 28

Schritt 7: Aus Schritt 6 haben wir gelernt, dass der HEAD auf die allerletzte Übertragung verweist. Versuchen wir also, uns nur den übergeordneten Commit anzusehen:

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 hat geklappt!

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

git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

Die sich nicht beschwert hat.

Schritt 9: Schauen Sie, was fsck sagt:

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 (inzwischen veralteten) Indexdatei zu stammen ( Quelle ). Also habe ich es beendet und das Repository zurückgesetzt.

rm .git/index
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: Nochmaliger Blick auf den fsck...

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

En Dangling Blobs sind keine Fehler . Ich bin nicht an master.u1conflict interessiert, und jetzt, wo es funktioniert, möchte ich es nicht mehr anfassen!

Schritt 12: Aufholen meiner lokalen Bearbeitungen:

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

git commit -a -m "recovering from the git fiasco"

[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

git add tex/sept2012_code/example-code-testing.R
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

Answer 2

Die Git-Objektdateien sind beschädigt worden (wie auch in anderen Antworten erwähnt). Dies kann z. B. bei einem Absturz des Computers passieren.

Ich hatte dasselbe Problem. Nachdem ich die anderen Top-Antworten hier gelesen hatte, fand ich den schnellsten Weg, das defekte Git-Repository mit den folgenden Befehlen zu reparieren (im Git-Arbeitsverzeichnis ausführen, das die .git Ordner):

(Stellen Sie sicher, dass Sie zuerst eine Sicherungskopie Ihres Git-Repository-Ordners erstellen!)

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

Dies wird zunächst alle leeren Objektdateien entfernen die das Repository als Ganzes beschädigen, und dann die fehlenden Gegenstände herbeischaffen (sowie die letzten Änderungen) aus dem entfernten Repository, und führen Sie dann eine vollständige Objektspeicherprüfung . Dies sollte jetzt ohne Fehler gelingen (es kann allerdings noch einige Warnungen geben!)

PS. Diese Antwort legt nahe, dass Sie eine Remote-Kopie Ihres Git-Repositorys irgendwo (z. B. auf GitHub) und das defekte Repository ist das lokale Repository, das mit dem noch intakten entfernten Repository verbunden ist. Wenn das nicht der Fall ist, dann versuchen Sie nicht, das Problem auf die von mir empfohlene Weise zu beheben.

Answer 3

Dieser Fehler tritt bei mir auf, wenn ich meine Übergabe vorantreibe und mein Computer hängen bleibt.

Ich habe das so gelöst.

---

Schritte zur Behebung

git status

Anzeigen der leeren/beschädigten Objektdatei

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

es entfernen

git status

Ich habe fatal: bad object HEAD Nachricht

rm .git/index

Ich entferne die index für das Zurücksetzen.

git reset

fatal: Das Objekt 'HEAD' konnte nicht geparst werden.

git status
git pull

Nur um zu überprüfen, was passiert ist

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

Es werden die letzten beiden Zeilen gedruckt, tail -n 2 des Protokollzweigs, um meine letzten beiden Commit-Hashes .

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Ich wähle die letzte commit hash

git status

Es zeigt alle meine Dateien als gelöscht denn ich habe die .git/index Datei

git reset

Weiter zum Reset

git status

Überprüfen Sie meine Korrektur

Answer 4

Ich habe das Problem gelöst, indem ich die verschiedenen leeren Dateien entfernt habe, die git fsck erkannt und dann ein einfaches Git-Pull ausgeführt.

Ich finde es enttäuschend, dass jetzt, wo sogar Dateisysteme Journaling und andere "transaktionale" Techniken implementieren, um das Dateisystem stabil zu halten, Git aufgrund eines Stromausfalls oder Platzmangels auf dem Gerät in einen beschädigten Zustand geraten kann (und sich nicht selbst wiederherstellen kann).

Answer 5

Ich hatte gerade dasselbe Problem: Nachdem ich das entfernte Repository gezogen hatte, wurde bei einer git status Ich habe:

"Fehler: Objektdatei (...) ist leer"
"fatal: loses Objekt (...) ist beschädigt"

Ich habe das Problem folgendermaßen gelöst:

1. git stash
2. Entfernen der Git-Datei aus Versehen (ich bin nicht sicher, ob dies notwendig war)
3. git stash clear

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