Michael J Gruber [off-list ref] writes:
quoted
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.
quoted
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?
quoted
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. Philip probably has a
confused notion that "rev-list A..B C..D" is somehow a union of set
A..B and C..D?
quoted
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.
From: "Junio C Hamano" <redacted>
Michael J Gruber [off-list ref] writes:
quoted
quoted
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.
quoted
quoted
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?
quoted
quoted
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?
quoted
quoted
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
Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
Michael J Gruber [off-list ref] writes:
quoted
quoted
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.
quoted
quoted
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?
I think you answered to e-mail (in-reply-to) and to Philip's actual text
(quotes), but just in case:
[git]✓ git rev-list --no-walk ^HEAD~3 HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
574dece7b651fbae385add51d7aaea1cc414007a
3fbbf6e9e40b151215cce6c6e25cd4db0232d870
[git]✓ git rev-list ^HEAD~3 --no-walk HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
The order of revision arguments and options does play role (but where I
put my HEAD does not, uhm), i.e. walk-options vs. negative refs.
The reason is that negative revs come with an implicit --do-walk (we
need to walk to mark uninteresting revs), and the last
--do-walk/--no-walk wins. That's what I meant with my comment.
But there is only one walk (or none), and one setting effective for all
revision arguments.
Michael
[So many typos, sorry]
Michael J Gruber venit, vidit, dixit 21.09.2016 16:46:
Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
quoted
Michael J Gruber [off-list ref] writes:
quoted
quoted
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.
quoted
quoted
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?
I think you answered to e-mail (in-reply-to) and to Philip's actual text
(quotes), but just in case:
"my e-mail"
[git]✓ git rev-list --no-walk ^HEAD~3 HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
574dece7b651fbae385add51d7aaea1cc414007a
3fbbf6e9e40b151215cce6c6e25cd4db0232d870
[git]✓ git rev-list ^HEAD~3 --no-walk HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
The order of revision arguments and options does play role (but where I
put my HEAD does not, uhm), i.e. walk-options vs. negative refs.
"play a role"
"negative revs"
The reason is that negative revs come with an implicit --do-walk (we
need to walk to mark uninteresting revs), and the last
"in order to mark"
--do-walk/--no-walk wins. That's what I meant with my comment.
But there is only one walk (or none), and one setting effective for all
revision arguments.
Michael