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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Apr 24, 2011, 11:28 UTC
Message-ID: <4DB40941.5030903@drmicha.warpmail.net>
In-Reply-To: <20110421213014.GB18418@elie>

Jonathan Nieder venit, vidit, dixit 21.04.2011 23:30:

Show 14 quoted lines

> 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