Git repository corrupt (incorrect header check; loose object is corrupt)

Question

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 Stack Overflow 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?

git log output (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.

Winton

perhaps try a git log or git log --oneline --decorate --all to see what the history looks like – Cipolin

Done. Not sure what you are looking for exactly, let me know if you want the full output or what. I wasn't doing anything fancy – Winton

Mostly just trying to figure out what ultimately is lost/inaccessible given the corrupt objects reported. Assuming you've got any uncommitted local changes saved somewhere else, are you able to git checkout each of the id's listed in the log? Makes me wonder if a brute-force solution would be to script over each of the id's, checkout the id, copy the working tree elsewhere (possibly a new git repository) to try and rebuild a non-corrupt repo. – Cipolin

Just read this post and was thinking it may be interesting to move the corrupt objects temporarily to another location and retry the git fsck --full to find out what currently references the offending objects. – Cipolin

Thanks @jkyako, that put me on the right track. Answer is forthcoming. – Winton

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

Winton

Also after those steps do del .git\index and git reset – Tiptoe

@Tiptoe Please elaborate. If there is a reason to do that I will add it to my answer, but it wasn't necessary in my case. – Winton

It was necessary in my case, as the index was corrupted also – Tiptoe

@Tiptoe How can you tell if the index is corrupted in a situation like this? Does it give an additional or slightly different error? – Winton

Yes, if you do git status for example even after all the steps you illustrated, it still said that it can't read object XXX. – Tiptoe

use git fetch after deleting to remake the files – Dipietro

Answer 2

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!

Ulent

git gc --prune=now just gives me the same error re: incorrect header – Bartley

this worked for me. Corruption happened twice in the last 5 commits. The first time I renamed the original folder, cloned the project again, then manually copied my (luckily few) changes. This time I had more changes, so I'm glad this command simply fixed it. – Trehala

Answer 3

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

Stanchion

It might "fix" the problem, but you will lose the corrupted files. – Talich

I attempted the accepted answer but it did not work for me, but wincent.com/wiki/Dealing_with_Git_repo_corruption worked and is similar to your thinking - with the big caveat that it loses track of local branches - I was lucky I had pushed to a remote branch before the files were corrupted since I could just fetch the changes after cloning – Impalpable

Answer 4

I landed on the same and fixed with a weird way, on Windows, Deleted the .git folder, Cloned the same repo on another folder Copied the .git folder from the new folder to the old repo then git add . git commit -m ... git push ....

Achene

Answer 5

I had the same issue and to solve it. delete .git folder and then run git init. this will create a new git folder and it will work.

Shastashastra