Julian Phillips <julian@xxxxxxxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
