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

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

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

Show 9 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > Could you instrument the code at the end of 
> > index-pack.c:parse_pack_objects() to display how many deltas were 
> > actually resolved and how many were not?  IOW is it a case of all or 
> > nothing, or is there an isolated case of corruption lurking somewhere?
> 
> fatal: packfile 'pack-ec0c3491753e115e1775256f6b7bd1bce4dea7cd.pack' has
> 18915 unresolved ref-deltas and 0 ofs-deltas among 21205

Hmmm....  Interesting.

Is it possible that sizeof(union delta_base) might not be equal to 20 for you?

Show 5 quoted lines

> By the way, "Gaaaah".  Is this find_delta() called from
> find_delta_children() doing the right thing?  I wonder if this
> is open to accidental collisions?. If you have an object name
> whose last 12-bytes are all NUL and you have a pack offset whose
> bytes happens to be a good prefix for an object, what happens?

It is filtered out later thusly:

	...
	for (j = ref_first; j <= ref_last; j++)
		if (deltas[j].obj->type == OBJ_REF_DELTA)
			resolve_delta(&deltas[j], data, ...);

So if a collision happens the object won't be of the right type and it is simply skipped.

Nicolas