Re: Inspecting a corrupt git object

From: Magnus Bäck <magnus.back@sonyericsson.com>
Date: Aug 4, 2010, 13:02 UTC
Message-ID: <20100804130229.GA1537@jpl.local>
In-Reply-To: <201008041148.49668.trast@student.ethz.ch>

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

Show 15 quoted lines

> 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