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