Johannes Schindelin <johannes.schinde...@gmx.de> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
