From: Felipe Contreras Date: Sun, 07 Apr 2013 18:02:41 GMT Subject: Re: [PATCH v3 4/4] format-patch: add format.cover-letter configuration Message-ID: In-Reply-To: <7v38v25k8b.fsf@alter.siamese.dyndns.org> On Sun, Apr 7, 2013 at 12:22 PM, Junio C Hamano wrote: > 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. 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