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 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