Re: [WRONG/PATCH 1/3] revisions: clarify handling of --no-walk and --do-walk
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- Apr 21, 2011, 13:03 UTC
- Message-ID
- <4DB02B24.4030503@drmicha.warpmail.net>
- In-Reply-To
- <20110421103926.GA16260@elie>
Jonathan Nieder venit, vidit, dixit 21.04.2011 12:39:
Show 35 quoted lines
> 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