On Sun, Apr 7, 2013 at 12:22 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html