Re: [RFH] convert shortlog to use parse_options

> 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.