Before you start reading, yes, the title is a shameless clickbait.
We all praise almighty
git. It is THE tool for source version control. It has all the options, all the commands, it is lightweight yet powerful… what could possibly be wrong?
Well, it seems that even
git has bad days. Some time ago, when I was doing heavy
rebase‘ing on a repository, I innocently typed
git status and received this anxiety-inducing message.
fatal: unable to read tree a6f3d17597b59ed9ed0c4b6a097e06f7acc4406b
fatal! I could expect this from someone else, but not from you,
Unfortunately, in this case using
reflog magic was not going to be quite enough, since the repository was really really broken (despair!). Seeing this, I took a deep breath and I did what everybody else would do, look for help in Startpage.com (there is life beyond Google).
After some unsuccessful Stackoverflow questions, I came across the only post that I was going to need. And it was not actually a post, it was a mail thread by no other than the man himself, Linus Torvalds!
In such thread, Linus talks about different tools that I did not know of. In particular, the most relevant one is
git fsck. The purpose of such tool is to, and I quote, “Verify the connectivity and validity of the objects in the database”. As you might remember,
git distinguishes three types of objects, which lay the foundation of its version control system, namely blobs, trees and commits. Each of them is related to each other, sort of forming the project history. The thing is that, if any of those objects gets corrupted (for example, if you remove a blob object from the
.git directory), then the whole thing breaks apart.
Consequently, our objective for saving our private repository is to find those corrupted objects and fix them. In my particular case, I was missing (only god knows why) a particular blob.
broken link from tree 716aa0ceed6f92d4026ac1f5615f7fd4fb38f12e to tree a6f3d17597b59ed9ed0c4b6a097e06f7acc4406b
The process from here is quite manual: find the particular version of the file that is causing the problem and re-generate its hash, so that it is available again and
git can make sense of its tree. I will not repeat the details here, since you can check Linus post about it, which is quite straightforward.
To my surprise, after an hour or so I was able to recover the repository to its original status. So I didn’t lose neither my developed code nor my job.
So the moral of the story is… do backups? (we should already know that). I suppose then that the real moral of the story is that even when
git gives you a
fatal error, it is still powerful enough to recover work that could have been lost forever.
That, and the fact that Linus Torvalds not only has devastating messages in email threads.