Subject: Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables

From: Junio C Hamano <[email-masked]>
Date: Wed, 08 Oct 2014 10:14:33 -0700

Matthieu Moy <[email-masked]> writes:

> Junio C Hamano <[email-masked]> writes:
>
>> Jakub Narębski <[email-masked]> writes:
>>
>>> Junio C Hamano wrote:
>>>
>>>>   - "[config] safe = section.variable" will list variables that can
>>>>     be included with the config.safeInclude mechanism.  Any variable
>>>>     that is not marked as config.safe that appears in the file
>>>>     included by the config.safeInclude mechanism will be ignored.
>>>
>>> Why user must know which variables are safe, why it cannot be left to
>>> Git to know which configuration variables can call external scripts?
>>
>> That's a fallback to let them take responsibility for variables we
>> do not mark as "safe"; and having that fallback mechanism lets us
>> keep the set of variables we by default mark as safe to the absolute
>> minimum.
>
> Perhaps this would need a way to say "this value is safe for this
> variable" too. I don't have a real use-case, but one could say something
> like "I'm OK with the file overriding core.editor, but the only values I
> accept are nano, vim and emacs".
>
> It doesn't seem to be a prerequisite to implement the safeInclude
> feature, but we should live room in the namespace for the day we want to
> add it.
>
> I don't have really good idea for it. The first I could think of was
>
> [config "safe"]
>     core.editor = nano
>     core.editor = vim
>     core.editor = emacs
>
> but it's not accepted by the current parser, hence not backward
> compatible.

Interesting thought (I've cc'ed Rasmus who did an RFC patchset on
the safe include feature).  I do not offhand think of a good example
of an variable that we may want to allow overriding but still want
to limit its values myself.  Almost all variables I would rather not
to see in-tree .gitconfig to touch at all, and the ones that I may
want to allow to be futzed with I can think of offhand are booleans.
With more people and time we might find a better example to illustrate
why we may want to have such a feature added.

Thanks.