Re: git-index-pack really does suck..

From: Junio C Hamano <junkio@cox.net>
Date: Apr 3, 2007, 22:31 UTC
Message-ID: <7vd52lum2f.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704031427050.6730@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 8 quoted lines

> Side note: with "alternates" files, you might well *always* have the 
> objects. If you do
>
> 	git clone -l -s ...
>
> to create various branches, and then pull between them, you'll actually 
> end up in the situation that you'll always find the objects and get back 
> to the really expensive case..

Ah, that's true. If you "git clone -l -s A B", create new objects in A and pull from B, the transfer would not exclude new objects as they are not visible from B's refs.

In that scenario, the keep-pack behaviour is already worse than the unpack-objects behaviour. The former creates a packfile that duplicates objects that are in A while the latter, although expensive, ends up doing nothing.

I wonder if we can have a backdoor to avoid any object transfer in such a case to begin with...