[Question] Git recovery with HEAD commit broken

I am not a developer for git, but i am a regular user with git, i came the following problem:

A power off cause my top commit broken, and then git branch/log/reflog..etc won't work. I do a hack that i change the HEAD commit to the one that i can make sure is right, and then i do:

# git reset --hard HEAD

In fact, i hope git fsck can fix up such problems(maybe can backup top commit for example)... Someone has faced such problems or have some suggestion for this?

Thanks, Wang

Shilong Wang <wangshilong1991@gmail.com> writes:

With a bit of luck, the reflog actually contain useful information. Look at .git/logs/HEAD (or refs/heads/* instead of HEAD for branches' reflog). It's a human-readable text format. You should be able to walk up the history looking for a good commit.

Before anything else: do a backup of your full repository while it's still time.

(don't forget to run "git fsck" to make sure that not only the commit but also its ancestry is right).

Not as far as I know. But "git fsck" has a --lost-found option that can help recovering unreachable (dangling) commits.

You may have a look at http://hackage.haskell.org/package/git-repair but I do not think it would solve your particular case.

Matthieu Moy wrote:

Well, let's find out.. I corrupted .git/refs/heads/master to refer to a commit that does not exist. The history has a few prior commits.

joey@darkstar:/tmp/yy>git fsck Checking object directories: 100% (256/256), done. error: HEAD: invalid sha1 pointer 10814e97cc8bf5f6f8ce0c0d5302f778c09cac88 error: refs/heads/master does not point to a valid object! notice: No default references

joey@darkstar:/tmp/yy>~/src/git-repair/git-repair 
Running git fsck ...
Initialized empty Git repository in /home/joey/tmp/tmprepo.0/.git/
1 missing objects could not be recovered!
To force a recovery to a usable state, retry with the --force parameter.
- exit 1

If there had been a remote that had the missing 10814e97cc8bf5f6f8ce0c0d5302f778c09cac88 commit, it would have cloned it from there, and this would have succeeded. But with a fully missing commit, --force is needed to enable more destructive repairs.

joey@darkstar:/tmp/yy>~/src/git-repair/git-repair --force
Running git fsck ...
Initialized empty Git repository in /home/joey/tmp/tmprepo.0/.git/
fatal: bad object refs/heads/master
fatal: bad object refs/heads/master
fatal: bad object refs/heads/master
Deleted these local branches, which could not be recovered due to missing objects:
	refs/heads/master
You currently have refs/heads/master checked out. You may have staged changes in the index that can be committed to recover the lost state of this branch!
Successfully recovered repository!
Please carefully check that the changes mentioned above are ok..

Hmm, that could have gone better. While it successfully detected the broken HEAD, and removed that ref, which is enough to make git fsck pass[1], it failed to find the old ref in the reflog, despite containing code that walks up it to find a usable commit.

joey@darkstar:/tmp/yy>git reflog fatal: bad default revision 'HEAD'

And that's why.. git-reflog requires a valid HEAD to work. Bit of a catch-22. I could work around this by manually parsing the reflog. It would not be the first thing git-repair has to re-implement because the git command isn't robust enough[2].

I have made a TODO about this. OTOH, if a kind git developer would like to make git-reflog work when HEAD is missing, that seems like a generally useful improvement..

Joey Hess wrote:

It's generally considered okay for everyday commands like "git branch -d" not to cope well with corrupted repositories, but we try to keep plumbing like "git update-ref -d" working to give people a way out. Is update-ref -d broken in this situation, too?

Curious, Jonathan