Re: heads-up: git-index-pack in "next" is broken

From: Nicolas Pitre <nico@cam.org>
Date: Oct 18, 2006, 02:23 UTC
Message-ID: <Pine.LNX.4.64.0610172209070.1971@xanadu.home>
In-Reply-To: <7vac3uif6i.fsf@assigned-by-dhcp.cox.net>

On Tue, 17 Oct 2006, Junio C Hamano wrote:

> The part you pointed out to me about "accidental collision"
> still bothers me somewhat.

I'll try to clear them away.

> Right now we do not produce ref-delta and ofs-delta in the same
> stream,

It is fully supported nevertheless.

> but if somebody did so then it would mean a disaster to have an 
> accidental collision of an 8-byte offset value plus 12-byte traiing 
> NUL and another base object whose object name happens to match that 
> pattern.

Not really. The only effect that would have on the sorted list of delta entries -- such sorting used to bring all deltas with the same base object contigously -- is that those deltas might not be perfectly contigous wrt their base object. This is why there is a test to skip deltas if they happen not to be of the expected type.

> I am actually Ok if we say the code assumes one stream has only
> ref-delta or ofs-delta and never both.

I'm perfectly OK with both types completely randomized.

> But then I suspect the first pass of parse_pack_objects() should
> make sure that assumption holds true for the pack being
> inspected and barf if it is not.

This is an unnecessary restriction though.

> Also the second pass do not have to run two find_delta_childs() calls 
> per delta object because by that time we know which kind would never 
> appear in the packfile.

True, but the flexibility is worth having I think. It makes the thing more robust instead of less.

> By the way can we call that find_delta_children() pretty please?

I have no problem with that.

Nicolas