How to recover a corrupted blob object

So exactly because the SHA-1 hash is cryptographically secure, the hash itself doesn’t actually tell you anything, in order to fix a corrupt object you basically have to find the "original source" for it.

The easiest way to do that is almost always to have backups, and find the same object somewhere else. Backups really are a good idea, and Git makes it pretty easy (if nothing else, just clone the repository somewhere else, and make sure that you do not use a hard-linked clone, and preferably not the same disk/machine).

But since you don’t seem to have backups right now, the good news is that especially with a single blob being corrupt, these things are somewhat debuggable.

First off, move the corrupt object away, and save it. The most common cause of corruption so far has been memory corruption, but even so, there are people who would be interested in seeing the corruption - but it’s basically impossible to judge the corruption until we can also see the original object, so right now the corrupt object is useless, but it’s very interesting for the future, in the hope that you can re-create a non-corrupt version.

This is the right thing to do, although it’s usually best to save it under it’s full SHA-1 name (you just dropped the "4b" from the result ;).

Let’s see what that tells us:

Ok, I removed the "dangling commit" messages, because they are just messages about the fact that you probably have rebased etc, so they’re not at all interesting. But what remains is still very useful. In particular, we now know which tree points to it!

Now you can do

which will show something like

and you should now have a line that looks like

in the output. This already tells you a lot it tells you what file the corrupt blob came from!

Now, it doesn’t tell you quite enough, though: it doesn’t tell what version of the file didn’t get correctly written! You might be really lucky, and it may be the version that you already have checked out in your working tree, in which case fixing this problem is really simple, just do

again, and if it outputs the missing SHA-1 (4b945..) you’re now all done!

But that’s the really lucky case, so let’s assume that it was some older version that was broken. How do you tell which version it was?

The easiest way to do it is to do

and that will show you the whole log for that file (please realize that the tree you had may not be the top-level tree, so you need to figure out which subdirectory it was in on your own), and because you’re asking for raw output, you’ll now get something like

and this actually tells you what the previous and subsequent versions of that file were! So now you can look at those ("oldsha" and "newsha" respectively), and hopefully you have done commits often, and can re-create the missing my-magic-file version by looking at those older and newer versions!

If you can do that, you can now recreate the missing object with

and your repository is good again!

(Btw, you could have ignored the fsck, and started with doing a

and just looked for the sha of the missing object (4b9458b..) in that whole thing. It’s up to you - Git does have a lot of information, it is just missing one particular blob version.

Trying to recreate trees and especially commits is much harder. So you were lucky that it’s a blob. It’s quite possible that you can recreate the thing.