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

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