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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Jakub Narębski <jnareb@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]