Re: [PATCH] introduce git root

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

 



Jeff King <peff@xxxxxxxx> writes:

> 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?
--
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]