2

I'm debugging a case of git repository corruption, caused by a hard drive failure. I have

>git fsck --full
fatal: loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349 (stored in
.git/objects/25/e9d8d2deb964c3da0f86f60bbd5a23e8387349) is corrupt

>git show 25e9d8d2deb964c3da0f86f60bbd5a23e8387349
fatal: loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349 (stored in
.git/objects/25/e9d8d2deb964c3da0f86f60bbd5a23e8387349) is corrupt

Now, I'd like to know something about this object - what it is, where does it belong ? (Which folder, which commit?)

When I try to investigate the object its stored in, I get:

>git show e9d8d2deb964c3da0f86f60bbd5a23e8387349
fatal: ambiguous argument 'e9d8d2deb964c3da0f86f60bbd5a23e8387349': unknown revision or
path not in the working tree. Use '--' to separate paths from revisions

How should I proceed?

I have a copy of the repository from earlier today, but I wouldn't want to just trash my local changes - I would prefer to see if I can fix the repo, or perhaps just trash a single commit.

P.S. - I found several threads about the "loose objects" problem, but nothing with concrete instructions on how to investigate/resolve, both in case where I do find a backup of the corrupt object in another repo, and in the case where there is no backup of this object.

P.S. 2 - Oddly enough, gitk --all works well and doesn't care about this corrupt state.

poke
  • 369,085
  • 72
  • 557
  • 602
ripper234
  • 222,824
  • 274
  • 634
  • 905
  • I would say the first thing is to use `git cat-file -p` to try to find out what kind of object it is. – Greg Hewgill Feb 20 '12 at 21:55
  • @Greg - output: `error: unable to unpack 25e9d8d2deb964c3da0f86f60bbd5a23e8387349 header error: inflateEnd: failed fatal: Not a valid object name 25e9d8d2deb964c3da0f86f60bbd5a23e8387349` – ripper234 Feb 20 '12 at 22:00
  • Ok, maybe try some of the other `cat-file` options to see what you can find out. – Greg Hewgill Feb 20 '12 at 22:02
  • Well, it seems I only have one commit there, and it looks like it's lost. No real chance to recover it, and since I work with small commits, not a lot of lost work. I'll just let this one go. – ripper234 Feb 20 '12 at 22:07
  • See also http://stackoverflow.com/q/223678/11343 – CharlesB Oct 27 '14 at 15:52

1 Answers1

2

The message “loose object 25e9d8d2deb964c3da0f86f60bbd5a23e8387349” tells you already the exact hash of said object; it’s 25e9d8d2deb964c3da0f86f60bbd5a23e8387349. Git just organizes objects in subdirectories by splitting off the first two characters for a separate directory. So that object is stored in /25/e9d8d2deb964c3da0f86f60bbd5a23e8387349, but that doesn’t change that its identifier is the full hash.

As such you would only need to use git show 25e9d8d2deb964c3da0f86f60bbd5a23e8387349. This however fails as the object is corrupt, so there is no real way to restore it.

The good message however is that “loose object” means that nothing is pointing on it, so if your repository is otherwise fine, you will not need that object.

Oddly enough, gitk --all works well and doesn't care about this corrupt state.

gitk – as well as nearly all other user commands from Git – only look at the objects reachable from HEAD or another named reference (branches, tags). So if there is a loose object, nothing is pointing at it, as such especially neither HEAD nor another named reference is pointing at it, and no error appears.

poke
  • 369,085
  • 72
  • 557
  • 602
  • `so if your repository is otherwise fine, you will not need that object.` - is there a way to simply revert the index to the last known good commit? Would something like `reset --hard` work on a corrupt repo? – ripper234 Feb 20 '12 at 22:50
  • I don’t think you really mean the index. But of course you can move HEADs to different commits using `reset --hard`. And as I said, your repository does not seem corrupt; just a single *loose* object is, so everything should be fine anyway. – poke Feb 21 '12 at 12:19