Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 2, 2015, 18:39 UTC
Message-ID: <xmqq7fw0uphd.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150201215729.GA19692@peff.net>

Jeff King <peff@peff.net> writes:

I didn't reply to the latter part of this message yesterday, because I wanted to think more on it.

Show 5 quoted lines

> But is it such a bad thing to have them in conflict? Can't we define a
> set of rules that does what people expects? For example, by the "last
> one wins" principle, any time we see "whitespace.tab-in-indent", it
> clears the setting of "whitespace.indent-with-non-tab", and vice versa.
> This isn't represented syntactically in the config file, ...

I agree. Both one-variable-per-knob and value-with-list-of-knobs do not express the semantic linkage between knobs; once we convince the users that one-variable-per-knob format does not mean they represent independent and orthgonal settings, the issue becomes a trade-off between

 * Is it concise to let end users skim through?
 * Is it easy to parse by scripters?

Show 15 quoted lines

> By the way, this is the exact case I am concerned about for fsck.*. Our
> use case at GitHub would be something like:
>
>   a. We set up sane defaults for fsck.* in /etc/gitconfig
>
>   b. User complains that we will not accept their push, which contains
>      objects with malformed committers.
>
>   c. Support investigates, determines that the malformed objects are
>      part of a well-established history, and that they are OK to enter.
>
>   d. We relax fsck.committerIdent in that repo's $GIT_DIR/config file.
>
> Copy-and-pasting the rest of the rules from (a) into the repo config
> file in step (d) is not ideal.

It probably can be worked around by the later-one-wins rule per item, e.g. after seeing "fsck.ignore = A B C" in /etc/gitconfig and then seeing "fsck.error = B" in $GIT_DIR/config, the latter will flip the three-way radio button for B from ignore to error (the other possible setting of the radio button is 'warn'), while leaving the three-way radio buttons for A and C set to ignore.

We can (and have to) do the same with "fsck.B = ignore" in /etc/gitconfig that gets overridden by "fsck.B = error" in $GIT_DIR/config, and that comes _free_, which makes it an attractive proposition.

As I already said, I am fine with "fsck.missingTagger = ignore".