[Question] Git recovery with HEAD commit broken

[Question] Git recovery with HEAD commit broken

[Shilong Wang]

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

Re: [Question] Git recovery with HEAD commit broken

[Matthieu Moy]

Shilong Wang <wangshilong1991@gmail.com> writes:

> A power off cause my top commit broken, and then git
> branch/log/reflog..etc won't work.

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.

> I do a hack that

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

> i change the HEAD commit to the one that i can make sure is right,

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

> In fact, i hope git fsck can fix up such problems(maybe can backup top
> commit for example)...

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
http://www-verimag.imag.fr/~moy/

Re: [Question] Git recovery with HEAD commit broken

[Joey Hess]

[-- Attachment #1: Type: text/plain, Size: 2933 bytes --]

Matthieu Moy wrote:
> 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.

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

-- 
see shy jo

[1] It will make fsck pass 100% of the time -- its test suite randomly
    corrupts repositories and checks that it can force some repair good
    enough to make git fsck pass.
[2] A particularly annoying one is that git branch -d cannot be used
    to remove a branch that is directly pointing to a corrupted commit!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Question] Git recovery with HEAD commit broken

[Jonathan Nieder]

Joey Hess wrote:

> [2] A particularly annoying one is that git branch -d cannot be used
>     to remove a branch that is directly pointing to a corrupted commit!

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