Hi Junio, On Mon, 22 Dec 2014, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Mon, 22 Dec 2014, Junio C Hamano wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> > >> > Of course you can say that! ;-) The problem these ugly messages try to > >> > solve is to give the user a hint which setting to change if they want to > >> > override the default behavior, though... > >> > >> Ahh, OK, then dashed form would not work as a configuration variable > >> names, so missingTaggerEntry would be the only usable option. > > > > Except that cunning me has made it so that both missing-tagger-entry *and* > > missingTaggerEntry work... > > Then the missing-tagger-entry side needs to be dropped. The naming > does not conform to the way how we name our officially supported > configuration variables. But it does conform with the way we do our command-line parameters, and it would actually cause *more* work (and more complicated code) to have two separate parsers, or even to force the parser to accept only one way to specify settings... Should I really introduce more complexity just to disallow non-camelCased config variables? Ciao, Dscho -- 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