92

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
trent
  • 25,033
  • 7
  • 51
  • 90
  • perhaps try a `git log` or `git log --oneline --decorate --all` to see what the history looks like – jkyako May 18 '14 at 23:21
  • 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 – trent May 19 '14 at 00:32
  • 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. – jkyako May 19 '14 at 18:41
  • 3
    Just read [this post](https://git.kernel.org/cgit/git/git.git/tree/Documentation/howto/recover-corrupted-blob-object.txt?id=HEAD) 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. – jkyako May 19 '14 at 22:38
  • 1
    Thanks @jkyako, that put me on the right track. Answer is forthcoming. – trent May 19 '14 at 23:43

4 Answers4

89

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.

trent
  • 25,033
  • 7
  • 51
  • 90
11

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

TooCooL
  • 20,356
  • 6
  • 30
  • 49
  • 10
    It might "fix" the problem, but you will lose the corrupted files. – Lawrence Dol Sep 20 '16 at 02:48
  • I attempted the accepted answer but it did not work for me, but https://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 – Nathan Beck Mar 15 '18 at 17:04
11

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!

BitBot
  • 458
  • 4
  • 14
  • 25
    git gc --prune=now just gives me the same error re: incorrect header – IcedDante Feb 01 '18 at 15:18
  • 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. – KYL3R Jul 13 '23 at 20:52
0

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

Same Arnold Nyaga
  • 11
  • 1