From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: "Rasmus Villemoes" <rv@rasmusvillemoes.dk>,
"Jakub Narębski" <jnareb@gmail.com>,
"Tanay Abhra" <tanayabh@gmail.com>,
git@vger.kernel.org, "Jeff King" <peff@peff.net>
Subject: Re: [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables
Date: Wed, 08 Oct 2014 10:14:33 -0700 [thread overview]
Message-ID: <xmqqy4sqbi12.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpqzjd7kta6.fsf@anie.imag.fr> (Matthieu Moy's message of "Wed, 08 Oct 2014 07:46:41 +0200")
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jakub Narębski <jnareb@gmail.com> 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.
next prev parent reply other threads:[~2014-10-08 17:14 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 13:24 [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 1/5] config.c : move configset_iter() to an appropriate position Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 2/5] make git_config_with_options() to use a configset Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 3/5] add "unset.variable" for unsetting previously set variables Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 4/5] document the new "unset.variable" variable Tanay Abhra
2014-10-02 13:24 ` [PATCH/RFC 5/5] add tests for checking the behaviour of "unset.variable" Tanay Abhra
2014-10-02 20:09 ` Junio C Hamano
2014-10-02 20:18 ` Tanay Abhra
2014-10-02 20:23 ` Junio C Hamano
2014-10-02 20:35 ` Tanay Abhra
2014-10-02 23:38 ` Junio C Hamano
2014-10-03 7:01 ` Matthieu Moy
2014-10-03 18:25 ` Junio C Hamano
2014-10-03 18:48 ` Junio C Hamano
2014-10-03 19:49 ` Matthieu Moy
2014-10-03 20:12 ` Junio C Hamano
2014-10-06 18:59 ` Tanay Abhra
2014-10-06 19:28 ` Junio C Hamano
2014-10-06 19:43 ` Tanay Abhra
2014-10-02 19:29 ` [PATCH/RFC 0/5] add "unset.variable" for unsetting previously set variables Junio C Hamano
2014-10-02 20:41 ` Jeff King
2014-10-02 19:58 ` Junio C Hamano
2014-10-07 11:17 ` Jakub Narębski
2014-10-07 16:44 ` Junio C Hamano
2014-10-08 5:46 ` Matthieu Moy
2014-10-08 17:14 ` Junio C Hamano [this message]
2014-10-08 18:37 ` Matthieu Moy
2014-10-08 19:52 ` Junio C Hamano
2014-10-10 8:11 ` Jeff King
2014-10-13 18:21 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy4sqbi12.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=peff@peff.net \
--cc=rv@rasmusvillemoes.dk \
--cc=tanayabh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.