Re: [RFH] convert shortlog to use parse_options

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I agree. I am already a little bit uncomfortable with the "--abbrev 10"
> won't work but "--foo 10" will, because it requires that the user
> remember which arguments are optional and which are required. But
> switching it to "--abbrev 10 works, but --abbrev $foo does not, unless
> of course $foo is an integer, in which case you must use --abbrev=$foo"
> is just a little bit too DWIM. E.g., if you are scripting, it's just one
> more source of error (if I have $foo, how must I write --abbrev $foo for
> it to ensure that I _don't_ trigger the optional argument?).

Oh, there is no question that scripted callers need a way to safely
disambiguate, and be able to call "git cmd" with always the default
abbreviation for whatever $foo it gets from the user unambiguously.

I do not disagree with that.

But that is different from making it harder for end users (not scripters
but command line users).

Again, I am not saying that my suggested alternative is superiour; I
just threw it out to as an example of a different approach to achieve
disambiguation than the "some flags must have its parameter stuck with
it, some don't" behaviour, which will surely be confusing to the command
line end users.

To contrast the two, with Pierre's, if you want $n-digit abbreviations
and $cnt-lines of output in your script, your script would say:

	git cmd --abbrev=$n -n $cnt $foo

because you as a script writer are required to know --abbrev is such a
magic flag that take optional parameter and cannot be fed as two options
(you can also write "-n=$cnt", but I am talking about --abbrev part).

If you are accepting the default abbreviation, on the other hand:

	git cmd --abbrev -n $cnt $foo

which looks nice.  The latter needs to be written in a funky way:

	git cmd --abbrev= $foo

if we take "empty parameter to a flag that take optional parameter means
use the default setting"; we could introduce a magic 'default' token to
read it slightly better:

	git cmd --abbrev=default $foo

but that does not change the fact that it makes it harder for
scripters.  I do not disagree with that.

The command line end users, who want to do the same, but has a bit more
concrete than unknown $n, $cnt, or $foo, can do

	git cmd --abbrev HEAD~4

in either approach.  However, with Pierre's, the command line end users
can say either:

	git cmd --abbrev=10 -n=4
	git cmd --abbrev=10 -n 4
	git cmd --abbrev=10 -n4

but they cannot say:

	git cmd --abbrev 10 -n 4

They need to learn the difference between --abbrev and -n, because you
avoid DWIMmery for the sake of script writers.  I have a slight
suspicion that it is backwards.

If there is _no_ existing users and previous versions of git, one
plausible alternative that would be much cleaner than anything we
discussed so far would be to always require '-n=4' (or "-n4") form and
never accept "-n 4", even for a flag that takes mandatory parameter.
Then there is no room for confusion.  Users (both command line end users
and script writers) need to learn only one rule: flag parameters are
always with the flag, not given as two words.

I really wish the world were that simple, but I do no think that would
fly well with the existing users' fingers.