Junio C Hamano <gitster@xxxxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> writes:
>
>> I think what's happening is that git-bundle actually runs _two_
>> traversals using the command-line arguments. ...
>> ... It was just a way of confirming my
>> guess about the double-read.
>>
>> The real solutions I can think of are:
>>
>> 1. Teach git-bundle not to require the double-read. I'm not sure why
>> it's written the way it is, but presumably it would be tricky to
>> undo it (or we would have just written it the other way in the
>> first place!)
>
> If I remember correctly, the reason why it does the double-read is
> because it wants to cope with things like "--since". There is no
> explicit bottom of the DAG specified on the command line, and the
> first one (without "--objects") is done to find "prerequisites" that
> are written in the header.
>
> Then the packdata is generated, which does another traversal (this
> time with "--objects" option).
>
> So perhaps the right way to fix it is to keep the first traversal
> as-is, but update the second one (I think write-bundle-refs is the
> culprit) so that it does not use the user-supplied command line
> as-is; instead it should use the positive end of the history from
> the command line with the negative end set to these "prerequisites"
> commits.
>
> I said "command line" in the above, but read that as "end user
> input"; the list of rev-list command line arguments given from the
> standard input is exactly the same deal.
Actually, after thinking a bit more about this, I think the bundle
we currently generate may be a bit less efficient than ideal when
options like --since or --max-count are used.
Imagine a history of this shape (child grows on the right hand side):
A---D-----E-----G---H
\ /
B---C---F
The labels on commits also denote their timestamps in relative
terms, i.e. A has the oldest timestamp, D, even though it is a
parent of B, has newer timestamp than B has, etc.
Now, imagine running "git log --since=$time H" with time set to the
timestamp commit D has. We traversal from H, following parent chain,
and stop when we see a commit with timestamp older than $time. So,
we'd enumerate H G F E D; C and A are "boundaries"---we looked at,
but we decided not to include in the result.
A bundle file format records "By using this bundle, you can advance
your history up to this commit", which can be seen by running "git
ls-remote" on the bundle file. It also records "However, this
bundle does not record the entire history; you need to have the
complete history behind these commits". These are called
"prerequisites", and can be checked with "git bundle verify".
And then of course it has an actual packfile (which is thin).
So putting all together,
git bundle create mybundle --since=$time H
would record H as its head, and also C and A as prerequistes.
The "double reading of --stdin" we have been discussing is there
because we run two traversals; the first one is to find the
prerequisites (i.e. C and A in the above example). The second one
uses the same rev-list arguments (i.e. "--since=$time H") to
generate pack, so it will include D.
As the recipient of a bundle is required to have complete history
behind both A and C, however, the packfile generated with the
current proceess is inefficient--it includes D but it does not need
to.
If we change the argument to rev-list used in the actual packfile
generation, and instead use the boundary we learned during the first
traversal (i.e. A and C in the above example) and the tip of the
history being recorded in the resulting bundle (i.e. H), then we'd
run "git log ^A ^C H", which would only walk "H G F E".
Which would be smaller (it no longer includes D), and the recipient
who has A and C can still apply.