Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Wed, 7 Mar 2007, Mark Levedahl wrote: > >> On 3/6/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html