Re: fact-import: failed to apply delta

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

Daniel Barkalow <barkalow@iabervon.org> wrote:
> 
> Is there some easy way to tell what object it was having problems with 
> when it failed to unpack? I've got a whole lot of objects.

Can you use gdb to find it?  If so, walk up the stack into
fast-import.c's load_tree() function and look at sha1 here,
and also, *myoe.
 
> The expected size of the base is 1882, while the actual size is 151. The 
> base offset it found was 12.
> 
> I'm using "checkpoint" a lot, so I've got 24 packs. Two of them have tree 
> objects of size 1882 at offset 12; a different one has a tree object of 
> size 151 at offset 12. The one with the object of size 151 was the one 
> that was still open at the end. There's no tree of size 1882 in this pack, 
> nor in any other pack that has a tree of size 151.
> 
> So maybe it's right about the offsets and all, but it's confused about 
> which pack something was in? Maybe it cached something when the pack 
> containing the object it wants was open, and it ended up thinking it was 
> in the pack that's now open rather than the pack that was open and is now 
> closed?

fast-import keeps all of its object data in a single table of
"struct object_entry", the table is keyed by SHA-1.  Each entry
has a pack_id, which tells it which pack this object is in, and
the offset of the object within that pack.

Sounds like maybe its confusing the pack pointer in the all_packs
array (see gfi_unpack_entry).
 
> I don't suppose there would be an easy way to figure out the object it was 
> trying to unpack by applying the delta?

Not really.  You'd have to write code for this.  Or, since the pack
closes and you can index it, use "verify-pack -v" to find the object
starting at the offset you know its having trouble with, that should
tell you the object's SHA-1.

-- 
Shawn.