Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> 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. 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.
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").
[Footnote]
*1* Does "--cover-letter yes" mean "--cover-letter=yes" aka "please
use cover letter" or is it "--cover-letter" (please use cover
letter) followed by an unrelated command line argument "yes"?
--
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