Re: [WRONG/PATCH 1/3] revisions: clarify handling of --no-walk and --do-walk

[Michael J Gruber <git@drmicha.warpmail.net>]

Jonathan Nieder venit, vidit, dixit 21.04.2011 12:39:
> As v1.6.0-rc2~42 (Allow "non-option" revision options in
> parse_option-enabled commands, 2008-07-31) explains, commands which
> use parse_options() but also call setup_revisions() do their parsing
> in two stages:
> 
>  1. first, they parse all options. Anything unknown goes to
>     parse_revision_opt() (which calls handle_revision_opt), which
>     may claim the option or say "I don't recognize this"
> 
>  2. the non-option remainder goes to setup_revisions() to
>     actually get turned into revisions
> 
> Some revision options, like --all and --not, are "non-options" in that
> they must be parsed in order with their revision counterparts in
> setup_revisions().  It would be nice if --no-walk and --do-walk fell
> in this category and set a flag only for revs coming after them on the
> command line, but they do not, so move parsing of --no-walk and
> --do-walk to the first "global options" stage for clarity.
> 
> ---
> Wait, the above is not actually the full story.  If I do
> 
> 	git show maint..master
> 
> then this turns on walking automatically, to give the commit range
> meaning.  Likewise
> 
> 	git log --no-walk maint..master
> 
> will, in fact walk, but
> 
> 	git log maint..master --no-walk
> 
> will not.  Which I should have understood from v1.6.0-rc2~42
> (2008-07-31) already.  Will think more; sorry for the nonsense.

This is not unrelated to the tip of gitster/mg/show-without-prune, i.e.

0c738b6 (builtin/show: do not prune by pathspec, 2011-04-01)

See http://permalink.gmane.org/gmane.comp.version-control.git/170461

We should rethink the ui balance between deviating from the usual log
option processing and the usefulness here.

Michael