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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 8, 2014, 19:52 UTC
Message-ID: <xmqqk34a8hl3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <vpq61fujtlk.fsf@anie.imag.fr>

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

Show 13 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
>
> I just thought of a semi-realistic use-case : diff.*.{command,textconv}.
>
> One may want to allow per-project sets of diff drivers, but these
> variables contain actual commands, so clearly we can't allow any
> value for these variables.
>
> "semi-realistic" only because I never needed a per-project diff driver,
> I have my per-user preference and I'm happy with it.

This may open another aspect of the discussion, actually.

The whole reason why the actualy diff.*.command and textconv commands are defined in .git/config while the filetype label is assigned by in-tree .gitattributes is because these commands are platform dependant. So textconv on Linux, BSD and Windows may want to be different commands, and the project that ships an in-tree .gitconfig to be safe-included may want to not "set" the variable to one specific value, but stop at offering a suggestion, i.e. "there are these possibilities, perhaps you may want to pick one of them?" without actually making the choice for the user.

And on the receiving side (i.e. [config "safe"] in .git/config), it is unlikely that you would list textconv choices that are plausible on different platforms. Rather, you would say "I would want this value to be set on textconv and not others".

But at that point, if you have to be that informed to set up the [config "safe"] to list allowed values, I wonder why a user chooses to do so and safe-include in-tree .gitconfig, instead of explicitly setting her preferred textconv in .git/config herself, without bothering to include anything.

> Anyway, the feature does not seem vital to me, but if someone comes up
> with a clever way to keep room for it in the namespace, that would be
> cool.

Yes.