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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Tue, 23 Dec 2014, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@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

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