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 23:30:
> Michael J Gruber wrote:
> 
>> 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)
> 
> True.
> 
>> We should rethink the ui balance between deviating from the usual log
>> option processing and the usefulness here.
> 
> Could you expand on that?  I think --no-walk being a positional
> argument is just an ugly consequence of the code that permits
> 

Sorry for being fuzzy. What I meant was: There is the systematic
approach which gives the user exactly what he asks for, i.e.: log,
rev-list default to walking, show to not walking (and rev-parse of
course), and when a user feeds a range it may or may may not make sense.
Similarly, "git show commit -- path" returns nothing at all if path is
not touched by commit because the commit gets pruned.

We don't do the systematic approach now. In some situations, some
commands switch on the walker automatically (I think "show A..B") to
make things more useful (to most users) but less systematic, even less
predictable if you don't know these deviations/exceptions. I've
suggested such a "usefulness exception" myself (don't prune commits by
path for "show").

The strict, systematic approach produces some command/argument
combinations which are not useful or rarely useful.

The "helpful" approach produces special casing which may make things
confusing if there's too much of it.

Finding the right balance is probably more difficult than being
radically systematic...

Michael