Re: Inspecting a corrupt git object

["Magnus Bäck" <magnus.back@sonyericsson.com>]

On Wednesday, August 04, 2010 at 11:48 CEST,
     Thomas Rast <trast@student.ethz.ch> wrote:

> Magnus Bäck wrote:
>
> > From what I gather from the community book and Pro Git, a git object
> > file is a deflated representation of the object type as a string,
> > the payload size, a null byte, and the payload. Is there a standard
> > tool for inflating the file back so that I can inspect what the
> > actual difference between these two are? Short of writing a tool
> > utilizing zlib, at least.
> 
> I'm sure it's a one-liner in almost any scripting language, e.g. you
> can use
> 
>   python -c 'import sys,zlib; sys.stdout.write(zlib.decompress(open(sys.argv[1]).read()))'
> 
> with a filename argument if you have Python at hand.

That worked fine, thanks. Apparently this difference in the second byte
of the compressed data makes no difference for the end result -- the two
inflated files are identical.

Interestingly, just as we were about to transplant the loose object from
my working repository to the server where "git gc" failed and the object
was seemingly corrupt, the person doing the actual work (I don't have
access to the server) ran "git gc" to find the id of the bad object, and
suddenly it completed without errors. The object in question had now
been included in a packfile, and upon unpacking that packfile to inspect
the object it was identical to the file I had, i.e. the new loose object
was different from the original loose object. I had expected a loose
object -> packfile -> loose object cycle to not change anything.
Everything seems to be back to normal now, which is good, but I prefer
I understand why things get fixed.

We did have some initial problems with reaching the per-process limit
for open files (as no repack had been done for an extended time and 5000
packfiles were lingering), but it seems weird for such a problem to be
related to the possible corruptness of a single tree object.

-- 
Magnus Bäck                      Opinions are my own and do not necessarily
SW Configuration Manager         represent the ones of my employer, etc.
Sony Ericsson