Re: How to undo previously set configuration?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 5, 2018, 11:21 UTC
Message-ID: <8737092929.fsf@evledraar.gmail.com>
In-Reply-To: <20180405104948.276de0ca.olaf@aepfle.de>

On Thu, Apr 05 2018, Olaf Hering wrote:

Show 6 quoted lines

> Am Thu, 05 Apr 2018 10:42:15 +0200
> schrieb Ævar Arnfjörð Bjarmason <avarab@gmail.com>:
>
>> I've been meaning to work on this but haven't figured out a good syntax for it (suggestions welcome!).
>
> Just prefix the knob with something like "no." or "-" or whatever to indicate that it never happened.

Those wouldn't work, respectively, because:

 a) For 'no.' there would be no way to override three-level keys,
    because prefixing such a key with "no" would introduce a 4th nesting
    level, which would be incompatible with existing config parsers.

 b) Similarly a prefix of - dies in git now. Unless I misunderstand
    you. I'm assuming you mean something like:

        [user]
        # This is an error
        -email

    Although I see we don't ignore or error out on:

        [user "-email"]
        foo=bar

   But that's back to problem a), and also looks ugly since you need
   something like the extra foo=bar so we'll pay attention to it.

Also it's important that the syntax leaves room for item #1 that I mentioned,

I.e. not just ignore stuff like user.email, but being able to specify where from you'd like to ignore that. Sometimes your local sysadmin is overzealous with his /etc/gitconfig settings and you'd like to quarantine just that, but pay attention to everything else in ~/.gitconfig, or similarly in /some/repo/.git/config ignore your usual custom sendemail.* from ~/.gitconfig but not /etc/gitconfig, so the semantics can't just be "clear existing".

But of course, you might say that it *should* be a syntax error because if you rely on this feature and downgrade, you don't want to suddenly pay attention to the sendemail.* config again.

I think that's an acceptable failure mode, and better than the syntax error, because that's exactly what we have now, so this is similar to e.g. the conditional include directive which was understood but just copmletely ignored by older versions.

So we're OK with getting different config between versions with new releases, but at all costs don't want to have new releases introduce constructs that older gits error out on, and let's say hypothetically we supported something like:

    [user "-email"]
    [user]
        email = ...

Even `git config -l` on older version won't show that "user.-email", and it's better if older tools at least understand the syntax, even though they don't pick up on the magic.