Re: [RFH] convert shortlog to use parse_options

[Andreas Ericsson <ae@op5.se>]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>> Junio C Hamano wrote:
>>
>>> ...  The
>>> "must stick" restriction feels Ok on paper but in practice it looks
>>> rather draconian and very user unfriendly.
>> Usually, optional arguments warrant adding a second parameter. This can
>> often even improve usability, as it's never unclear or ambiguous what's
>> happening. For the 'git tag -l' case, I'd use something like
>> 'git tag -l --match="regex"' or some such,...
> 
> That is essentially arguing for POSIXly correct "do not allow optional
> option-arguments" (utility syntax guidelines #7).  That position might
> be politically correct, but I am already discussing beyond that:
> usability.
> 
> For "git tag -l", the fix was rather simple, as the option would either
> have taken a zero pattern (list all) or a single pattern (list matching
> this pattern), and the command itself did not take any extra arguments,
> so that was what I did in the patch.  Compare your POSIXly correct
> version:
> 
>         git tag -l			(ok)
>         git tag -l pattern		(not ok)
> 	git tag -l --match=pattern	(ok)
> 
> with the traditional (and fixed):
> 
>         git tag -l			(ok)
>         git tag -l pattern		(ok)
> 	git tag -l pattern garbage	(not ok)
> 
> Which one is easier for the user?


git tag -l pattern, although I suspect newcomers often write it as
"git tag -l | grep pattern" anyways.

If -l was a short-hand for "git tag list", and "list" was a subcommand
to git tag, the whole business would be explainable. The fact that
"git tag" lists all tag but doesn't take a patter, while "git tag -l"
does exactly the same thing, but *does* take an (optional) pattern
means the --match functionality could just as well be written as
"git tag -m pattern" (and let '-m' imply '-l', which is sensible).
"-l" can then be deprecated, as its syntax doesn't match that of
the other way to list tags.

Otoh, I don't care all that deeply about it. It's just nicer to explain
the UI if there are no optional arguments, primarily because it involves
exceptions, and secondarily because many programs follow the posixly
correct thing of "no optional arguments", so they're a definitive
minority in the program argument jungle.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231