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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.