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

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

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.

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

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