Hi Junio, On Tue, 23 Dec 2014, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Okay, so just to clarify: you want me to > > > > - split the parser into > > > > - a parser that accepts only camelCased variable names when they > > come from the config (for use in fsck and receive-pack), and > > OK. > > > - another parser that rejects camelCased variable names and only > > accepts lower-case-dashed, intended for command-line parsing > > in fsck, index-pack and unpack-objects, and > > > > - consequently have a converter from the camelCased variable names we > > receive from the config in receive-pack so we can pass lower-case-dashed > > settings to index-pack and unpack-objects. > > I am not sure about the latter two. This needs a design discussion > what the command line options should be. > > I think the command line should be like this: > > git cmd --warn=missingTags,missingAuthor Okay. This contradicts the convention where Git uses lower-case-dashed command-line option values (e.g. on-demand, error-all, etc) and no camelCased options were present so far. But your wish is my command. Ciao, Dscho > > in the first place, i.e. "we may invent tokens to denote new kinds > of errors as we improve fsck", not with "we may add options for new > kinds of errors", i.e. the command line should not look like this: > > git cmd --missing-tags=warn --missing-author=warn > > And from that point of view, I see no reason to support the dashed > variant anywhere in the code, neither in the config parser or in the > command line parser. > -- 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