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

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> >> > Of course you can say that! ;-) The problem these ugly messages try to
>> >> > solve is to give the user a hint which setting to change if they want to
>> >> > override the default behavior, though...
>> >> 
>> >> Ahh, OK, then dashed form would not work as a configuration variable
>> >> names, so missingTaggerEntry would be the only usable option.
>> >
>> > Except that cunning me has made it so that both missing-tagger-entry *and*
>> > missingTaggerEntry work...
>> 
>> Then the missing-tagger-entry side needs to be dropped.  The naming
>> does not conform to the way how we name our officially supported
>> configuration variables.
>
> But it does conform with the way we do our command-line parameters,

Hmmm....  What is the expected user interaction?  The way I read the
series was ($MISSING_TAGGER stands for the "token" we choose to show):

    (1) The user runs fsck without customization, and may see a
	warning (or error):

        $ git fsck
        error in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: $MISSING_TAGGER

    (2) The user demotes it to warning and runs fsck again:

	$ git config fsck.$MISSING_TAGGER warn
        $ git fsck
        warning: tag d6602ec5194c87b0fc87103ca4d67251c76f233a: $MISSING_TAGGER

I suspect that it would be much better if the configuration
variables were organized the other way around, e.g.

	$ git config fsck.warn missingTagger,someOtherKindOfError

Then a one-shot override would make sense and easier to give as
command line option, e.g.

	$ git fsck --warn=missingTagger,someOtherKindOfError

But the proposed organization to use one variable per questionable
event type (as opposed to one variable per severity level) would
lead to a one-shot override of this form, e.g.

	$ git fsck --missing-tagger=warn --some-other-kind-of-error=warn

which I think is insane to require us to support unbound number of
dashed options.

Or are you saying that we allow "git config core.file-mode true"
from the command line to set core.fileMode configuration?

Puzzled...