Re: Debugging corrupt object generation

["Shawn O. Pearce" <spearce@spearce.org>]

Julian Phillips <julian@quantumfyre.co.uk> wrote:
> On Thu, 1 Nov 2007, Nicolas Pitre wrote:
> >
> >Maybe fast-import hasn't flushed the needed data to the pack yet?
> 
> Well, fast-import completes quite happily and outputs the normal summary 
> status.  I can look at logs and trees etc provided that I don't try and 
> look at one particular part of the tree on one particular commit.  I 
> think the problem is that I've managed to do something inside fast-import 
> that corrupts one particular tree object (though I've no idea what that 
> might be).

Ahhh.  I'm betting you messed up the version 0 and version 1 arrays
inside of the struct tree_entry.  This could cause the delta
generator to look at the wrong base information when it creates
the delta, thus causing the delta to be created for a different
base than what the object is actually using in the packfile.

The version[0] is meant to hold the mode and SHA-1 of the tree_entry
in the base object.  The version[1] is meant to hold the current
mode and SHA-1 of the tree_entry in the new object.  A mode of 0
means the entry doesn't exist in that particular tree; so an add
is shown as "version[0].mode = 0; version[1].mode = 0100644".

Look at the store_tree function, this is where we regenerate the
canonical representation of both the version[0] and the version[1]
trees so the store_object function can generate a delta.  Note that
we assume the base object name is root->versions[0].sha1.  Maybe the
version[0] array doesn't actually match the tree named by that sha1?

-- 
Shawn.