From: Junio C Hamano Date: Sun, 07 Apr 2013 17:22:28 GMT Subject: Re: [PATCH v3 4/4] format-patch: add format.cover-letter configuration Message-ID: <7v38v25k8b.fsf@alter.siamese.dyndns.org> In-Reply-To: Matthieu Moy 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"?