Re: [RFH] convert shortlog to use parse_options

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 13, 2007, 20:46 UTC
Message-ID: <7vk5ni1fwh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1197571656.28742.13.camel@hinata.boston.redhat.com>

Kristian Høgsberg <krh@redhat.com> writes:

Show 7 quoted lines

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