Re: clarification of `rev-list --no-walk ^<rev>`?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 19, 2016, 16:12 UTC
- Message-ID
- <xmqq8tunhns4.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <3b06b9ee-3975-acf1-41d8-02b774a2dd3c@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 11 quoted lines
>> 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. Philip probably has a confused notion that "rev-list A..B C..D" is somehow a union of set A..B and C..D?
>> 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.