Corrupted files in Git

Solution 1:

Some kind soul wrote a script to do this automatically (and more thoroughly), but the process to recovery is basically this:

1. Examine the file that reports garbage, with hexdump.

   $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

   You're looking for a part of the file where there's a huge span of zeros. If there are multiple such spans, I've had good luck (N = 2) when considering just the first giant set of zeros, even when they included small runs of nonzero data. This is the "garbage" that git is complaining about.

   ...
   0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
   0000510 0000 0000 0000 0000 0000 0000 0000 0000
   *
   0001000             # ... almost 3kb of zeros.
   

   You can determine from this the real size of the object. Here, it would be 0x504 or 1,284 bytes.

2. Make a backup copy of the object. In case you pick the wrong set of zeros, you can try again with a different set.

   $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

3. Truncate the file to its appropriate length.

   $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0
   

The corrupt object should now be fixed. Assuming it was the only one, cloning/pushing/pulling the repository should now work as expected.

Citing my sources, I believe I have experienced the same issue, but in my case using Ubuntu 10.4 (kernel 2.6.32-23-generic). In this case, it is a filesystem bug that has not been tracked down yet. There is an open issue on ecryptfs on this subject and also a related usenet thread. Along the way to a solution, I found a handy answer and summary on StackOverflow. The linked article was very interesting, though I ultimately went a different way.