From: "Junio C Hamano" <>
Michael J Gruber <> 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 " 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, 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.


Reply via email to