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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 23, 2014, 16:32 UTC
Message-ID: <xmqqmw6e499u.fsf@gitster.dls.corp.google.com>
In-Reply-To: <alpine.DEB.1.00.1412231049250.21312@s15462909.onlinehome-server.info>

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

Show 15 quoted lines

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