[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: >> 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? > > 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 >