On Sun, Apr 7, 2013 at 12:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
>>> Wouldn't this work for both cases?
>>> % git -c format.coverletter=auto format-patch
>> Then, what's the point in having a --cover-letter option?
>> "git -c" is a good last-chance solution, but when we provide the same
>> feature as a command-line option and as a configuration option, I can
>> see no reason to add subtle difference between them.
> I do not see a good reason to resist consistency by suggesting a
> workaround.

There's no need for a workaround, because there's no use-case.

> We may do so ourselves when responding to an end user
> bug report "I cannot countermand X from the command line" as a first
> response "In the meantime you can work it around like so", but that
> is as you said a last-resort workaround and does not justify why the
> command line interface is lacking an obvious override.

The command line interface is not missing anything.

> But I think --cover-letter=auto I made was a bad suggestion.  An
> optional parameter to a command line option is generally bad, as it
> makes the parsing ambiguous [*1*], and turning what traditionally
> was a boolean without any parameter into one that takes an optional
> parameter is even worse.
> We should instead add this as a new feature, --auto-cover-letter, or
> something, i.e. the synopsis will have these as the choices
>     [--[no-]cover-letter|--auto-cover-letter]
> and the last one would win (e.g. "--cover-letter --auto-cover-letter"
> would mean "auto").

Well, go ahead and implement it, because I'm not going to waste my
time implementing something nobody will *ever* use.

Felipe Contreras
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to