From: Junio C Hamano <junkio@cox.net>
Date: Wed, 07 Mar 2007 23:32:11 GMT
Subject: Re: [PATCH] git-bundle: fix pack generation.
Message-ID: <7vfy8geikk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0703072330200.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 7 Mar 2007, Mark Levedahl wrote:
>
>> On 3/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> > 
>> > > git-bundle create test.bdl HEAD --since=1.day.ago ==>> pack with 
>> > > 1531 objects
>> > 
>> > Did you test with "--since=1.day.ago HEAD", i.e. with the correct 
>> > order? I know you'd like the options to be interminglable, but "HEAD" 
>> > really is not an option, but an argument.
>> 
>> Changing the order of arguments makes no difference, same result either 
>> way.
>
> We don't do thin packs. Should we? I guess that 
>
> 	$ git ls-tree -r HEAD | wc
>
> results in something close to 1500 in that repo. Which basically means 
> that the 1531 objects (including trees and the commit) sounds correct.

We should do thin packs, but 1500+ objects is a different story.

	rev-list --objects <revspec>

means "show me the revs and its objects".

	rev-list --max-count=<n> <revspec>

means "show me the revs and its objects, but stop at <n> revs".

On the other hand, 

	rev-list --objects ^<rev1> <rev2>

means something totally different.  "never show me what is
reachable from <rev1> but I am interested to see what are
reachable from <rev2>".

So it is natural that "rev-list --objects --max-count=1 HEAD"
shows the same set of tree and blob objects as "git-tar HEAD".
"show me the revs and its objects" does not say "but exclude
trees and blobs reachable from commits beyond the <n> revs
boundary," which is "rev-list --objects HEAD^..HEAD".

In other words, "rev-list -1 HEAD" and "rev-list HEAD^..HEAD"
are _different_.

We fixed (in 'next') the revision traversal so that --max-count
and --boundary interact correctly.  What's not fixed is that we
still use "rev-list --objects --max-*" given by the user, which
is not the semantics git-bundle wants.  We should rewrite the
revspec to drive pack-objects when generating the packfile part
of the bundle to do "<revs> --not <boundaries>" internally in
git-bundle.