Git repository corrupt (incorrect header check; lo

问题:

I experienced a power failure yesterday evening while writing a commit message. When I booted the machine back up I couldn't complete the commit. I ran git reset, added back the changed files, and tried again, and got this:

% git commit
error: inflate: data stream error (incorrect header check)
error: unable to unpack a94406345ac44982b00cf57b4b9660a35436637f header
fatal: a94406345ac44982b00cf57b4b9660a35436637f is not a valid object

git fsck reveals the following:

% git fsck --full
Checking object directories: 100% (256/256), done.
error: inflate: data stream error (incorrect header check)
error: unable to unpack 4346883490a0990e68db0187241abc1642765a73 header
error: inflate: data stream error (incorrect header check)
fatal: loose object 4346883490a0990e68db0187241abc1642765a73 (stored in .git/objects/43/46883490a0990e68db0187241abc1642765a73) is corrupt

I notice the messages are complaining about different objects.

I searched SO and the Web and tried a few different things but to no avail.

• I don't have a recent backup copy.
• Cloning the repository into another directory doesn't help; the new repository exhibits the exact same problems.
• git stash gives the same message as git commit. All the other git commands seem to work normally.

How can I tell what is wrong and fix it?

Edit: git log output as suggested (just the first few lines):

% git log --oneline --decorate --all |head -n 8
253b086 (HEAD, new_tokenize) Normalized tokenizer interface slightly
0f2425a (master) Added procs to eval layer
a4d4c22 Added procedures as a type
d1e15ad (tag: v0.10) Added `if' form with tail call semantics
f94a992 (tag: v0.9) Completed environments
031116e Fixed bug where # on a line by itself caused segfault
3d8b09f Added environments, define and set!
01cc624 Put symbol table implementation into types.c

This is a small personal project; I usually just work in (master) but I was doing an experiment at the time (new_tokenize). 253b086 was the last successful commit before the power failure.

回答1:

It appears that git created files in .git/objects for the new commit, but didn't successfully write to them. I solved it by deleting them one at a time and re-running git fsck --full to find the next one. I started with the one originally reported by git fsck:

% rm -f .git/objects/43/46883490a0990e68db0187241abc1642765a73
% git fsck --full
Checking object directories: 100% (256/256), done.
error: inflate: data stream error (incorrect header check)
error: unable to unpack 86e7247af5865e857a3b61eed99986e2d9538df1 header
error: inflate: data stream error (incorrect header check)
fatal: loose object 86e7247af5865e857a3b61eed99986e2d9538df1 (stored in .git/objects/86/e7247af5865e857a3b61eed99986e2d9538df1) is corrupt
% rm -f .git/objects/86/e7247af5865e857a3b61eed99986e2d9538df1
% git fsck --full
Checking object directories: 100% (256/256), done.
error: inflate: data stream error (incorrect header check)
error: unable to unpack a94406345ac44982b00cf57b4b9660a35436637f header
error: inflate: data stream error (incorrect header check)
fatal: loose object a94406345ac44982b00cf57b4b9660a35436637f (stored in .git/objects/a9/4406345ac44982b00cf57b4b9660a35436637f) is corrupt

And so on. I deleted five objects before git fsck came up clean, corresponding (as I suppose) to the five files in the commit I was trying to make. I guess that the file history was not corrupted at all.

Incidentally, I thought of another method that seems to work as well. git clone copies the bad objects, but git push does not. After backing up, I created a new empty repository (--bare, because otherwise you can't push to master), then unstaged my changes and pushed both branches into the new repository. Then it was just a matter of checking it out again and restoring the latest changes from my backups.

Still interested if anyone cares to shed light on the failure mechanism here.

回答2:

Simple answer to this question for anyone facing this problem: the git clone command is the fix, if have a remote repo then clone it to the local folder (after deleting the corrupted local repo), in case you dont have remote repo then try to push the corrupt repo to github and then clone it from there, I think that corrupted objects wont be pushed and it will fix the problem

回答3:

As described in this answer I ran:

git reflog expire --expire-unreachable=now --all
git gc --prune=now

Which removed all of my dangling blobs and dangling commits, as well as the corrupt db objects.

It was a lot faster than tracking them down one-by-one!