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

From: Junio C Hamano <junkio@cox.net>
Date: Oct 18, 2006, 01:30 UTC
Message-ID: <7vac3uif6i.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0610171959070.1971@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 22 quoted lines

> So let me summarize:
>
>  - the union is a hash.
>
>  - the hash is either an offset value or a sha1 digest.
>
>  - this hash is used for fast object lookup _only_.
>
>  - it does sort differently on big vs little endian machines.
>
>  - but we don't care at all because
>
>  - it is a private algorithmic thing that doesn't "bleed" into any 
>    _real_ data structure, and
>
>  - it doesn't have any influence on the format of the end result.
>
>  - it is only a runtime abstraction and nothing else.
>
>  - It never gets into the pack nor the pack index themselves.
>
> Do you still have issues with that?

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

Right now we do not produce ref-delta and ofs-delta in the same stream, 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.

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

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. 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.

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