Philip Oakley venit, vidit, dixit 19.09.2016 12:56: > A question came up on the Git user list regarding cherry-pick that got me > reading the manual (again), in this case regarding --no-walk ranges. > > Essentially my question is: If --no-walk is given to rev-list (e.g. via > charry-pick), and the user includes a caret prefixed rev, when does that > range definition take effect on the command line, especially in light of > the --do-walk option? > > In rev-list(1) there are only 8 references to 'range', with only > the --no-walk option saying "This has no effect if a range is specified." > but leaving open the decision as to what does (and does not) comprises the > specification of a range on the cli. > > The two and three dot notations are fairly obvious ranges from > gitrevisions(7) as they are complete strings, while the caret prefix is an > implied range (it needs additional parameters to complete the range, and > there-in lies the issue). > > 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 > > because the ^ caret starts the range that cancels the --no-walk. > > Clearly that's not what is intended, which is > > $ git cherry-pick --do-walk maint next ^master > > 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. > > 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?
Maybe: Every negative rev (rev prefixed with ^, or a range) implies a `--do-walk` (right at its position on the command line). And then curb the misleading range sentence in the `--no-walk` description. Michael
