Re: [RFH] convert shortlog to use parse_options

Kristian Høgsberg [off-list ref] writes:

Oops, sorry about that.  I just wanted to say we shouldn't jump through
all these hoops to make the option parser support every type of option
there ever was in the git command line ui.  A lot of these were probably
decided somewhat arbitrarily by whoever implemented the command.
Instead it's an opportunity to retroactively enforce some consistency
and predictability to the various option-styles that have been
hand-rolled over time in different git commands.

That principle is fine, but I do not think it is relevant to what is
being discussed.  The issue is what to do with a flag that can
optionally take a parameter but works fine without because it has a
default.

 * You can obviously disallow such a flag, and call the result
   "consistent".  I do not think we want to go that route.  --abbrev, -M
   (to diff) and -w (to shortlog) are good examples why this is a good
   thing.  You want to use the default most of the time, but want to be
   able to tweak the value sometimes.

 * You can alternatively require parameters to such a flag always stuck
   with the flag, which is what Pierre did.  I suspected that is
   introducing an inconsistency and may be confusing to the users ("I
   can write -n=1 or -n 2, but why not --abbrev 7???") and wanted to see
   if somebody can come up with a better alternative.

 * You can try to make the parser a bit more context sensitive by
   looking at the possible parameter and see if it is plausible, which
   hopefully would work for most of the real life cases (e.g. "--abbrev
   7 HEAD" vs "--abbrev HEAD").  I however agree with Pierre that "DWIM
   works most of the time" is not good enough if there is no way to
   disambiguate in cases that fall outside.