Re: [PATCH] git-bundle: fix pack generation.

Johannes Schindelin [off-list ref] writes:

On Wed, 7 Mar 2007, Mark Levedahl wrote:

quoted

On 3/6/07, Johannes Schindelin [off-list ref] wrote:

quoted

quoted

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.