From: Junio C Hamano Date: Thu, 13 Dec 2007 20:46:54 GMT Subject: Re: [RFH] convert shortlog to use parse_options Message-ID: <7vk5ni1fwh.fsf@gitster.siamese.dyndns.org> In-Reply-To: <1197571656.28742.13.camel@hinata.boston.redhat.com> Kristian Høgsberg 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.