Re: [PATCH] introduce git root

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2014, 21:08 UTC
Message-ID: <xmqq7fxzgql2.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141210201057.GC23273@peff.net>

Jeff King <peff@peff.net> writes:

Show 15 quoted lines

> On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
>
>> This is another tangent that comes back to the original "how to name
>> them?" question, but I wonder if a convention like this would work.
>> 
>>  * When asking for a feature (e.g. "what editor to use"), if there
>>    is a git-specific environment variable that can be set to
>>    override all other settings (e.g. "$GIT_EDITOR" trumps "$EDITOR"
>>    environment or "core.editor" configuration), "git var" can be
>>    queried with the name of that "strong" environment variable.
>
> I'd prefer to create a new namespace. When you set $GIT_EDITOR as a
> "trump" variable, then that is leaking information about the computation
> from "git var" out to the caller. What happens if the computation
> changes so that $GIT_EDITOR is no longer the last word?

Having two classes of variables, ones that have their corresponding "trump" environment variables and others (and making the users aware of the "trump" variables) is a way to teach users that they could use them when they want to tweak the specific aspect of Git. It of course casts what variable trumps all others in stone, which is a prerequisite if we want to have something stable and teachable to the users. Casting in stone will hinder future improvements, so the argument cuts both ways.

Having said that, this was not even a suggestion or a proposal (in the sense that I would be happier if people agreed on this design rather than other design). I'd be happy as long as people agreed on anything sensible.

> So now you have two classes of variables. Some that look like
> environment variables, and some that do not. What does it buy you for
> the ones that do look like environment variables?

Teachability. I personally do not care too much about it, though ;-)

I would have used a separate namespace for the ones without "trump" variables, and would have given aliases in that namespace even for the ones with "trump" variables, so it does not make much difference to my mind---we will have the third namespace anyway whether we went the "trumps can be queried via the environment variable name" option or not.

So it seems that we agree that a separate namespace that is clearly distinct from environment or config would be the way to go?