Subject: Re: [PATCH 16/18] fsck: support demoting errors to warnings

From: Junio C Hamano <[email-masked]>
Date: Tue, 23 Dec 2014 09:56:06 -0800

Johannes Schindelin <[email-masked]> 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.