From: "Junio C Hamano" <gitster@xxxxxxxxx>
Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
It can be read that
$ git cherry-pick maint next
would pick two single commits, while
$ git cherry-pick maint next ^master
could implicitly be read as
$ git cherry-pick maint next --do-walk ^master
You can read it as "master..next maint" that does force walking.
Clearly that's not what is intended, which is
$ git cherry-pick --do-walk maint next ^master
I do not see the distinction betwee the above two you seem to be
trying to make. Care to explain?
but it is open to interpretation as to where in the command line the
caret
range prefix's --do-walk (to countermand the --no-walk) should applied.
I do not think it can be position dependent.
OK. (background, long story) When I first read the man page, and in trying
to explain a user confusion between cherry pick commits and am'ing the same
commits via format-patch (where sometimes the patches had coverlapping
context issues), I was trying to confirm for myself that 'git cherry-pick B
C' and 'git cherry-pick C B' should get the same end result, and not be
mistaken (e.g. user misunderstanding) for a range.
I first spotted the 'git help cherry-pick's line:
<commit> - no traversal is done by default, as if the --no-walk option was
specified, see git-rev-list(1).
So off I goes to rev-list, and see that the options no-walk/do-walk are said
(implied) to be position dependent.
--do-walk - Overrides a previous --no-walk.
Meanwhile the --no-walk option says:
--no-walk - This (option) has no effect if a range is specified.
So at this point I am wondering about the command line ordering and what
comprises the range if the negative ref is given last, or at least just
before a --do-walk.
Thus (at this point) it felt like one of those specification rabbit-holes
that I often see at $dayjob. It was unclear as to the point at which the
'range' was to be applied in to the command line to get the expected
examples.
Climbing back out of the rabbit-hole. I now see that after the end of the
cherry-pick <commit> line I quoted, there is a secondary "Note that
specifying a range will feed all <commit>. arguments to a single revision
walk", which at the time did not register (a classic human error.. Three
Mile Island et al.).
Similarly, in the rev-list --no-walk option, its says (mid-para) "This has
no effect if a range is specified." so in some ways that confirms the cherry
pick statement, but again a less obvious corollary.
However, there is still a small step missing, which is to confirm that using
a negative ^ref anywhere(?) makes the whole list of refs into a range (i.e.
it will look-back along the command line) to cancel any --no-walk options in
place.
Given that a walk usually requires a range, I'm now having difficulty seeing
how the --no-walk <revs> --do-walk can be combined anyway.
The bits I felt was missing (in the docs) was to say explicitly somewhere
that a negative ref defined that we had a range (to link back to those
walk-no-walk statements), and the extent of rev paramaters it applied to.
And after re-reading, that some of those corollary statements about ranges
flipping the walk-no-walk condition should be brought forward to be more
obvious within the primary rev-list (to avoid the typical reader error).
Philip probably has a
confused notion that "rev-list A..B C..D" is somehow a union of set
A..B and C..D?
That wasn't the issue. Though it does beg the question that it's the same as
"rev-list D B ^A ^C" isn't it?
If the user did want just the single commit at the tip of maint, and
then
the range master..next, what would be their command line, and also, how
would the man page warn against false expectations?
Yeah, this can show us that all of the have is coming from that
exact confusion I suspected Philip has. We need to clarify in the
documentation that rev-list set operation does *NOT* have union of
multiple sets to unconfuse the readers.
I'd say it was the walk - no walk range confusion. Inclusion of any range
definition of any sort (in particular ^rev) causes the expectation that an
ordered list of single revs can be included, to be broken.
i.e. cherry-pick B D F G Q..T; isn't B D F G R S T, is it?
I've also have a quick browse of the test scripts and didn't see any tests
that actually cover the example of `git cherry-pick maint next ^master`
where both have multiple commits to pick, so couldn't see what the test
would expect.
--
Philip