Re: [RFH] convert shortlog to use parse_options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
Andreas Ericsson <ae@xxxxxx> 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@xxxxxx
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux