Kristian Høgsberg <krh@xxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
