Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] introduce git root

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:16

Jeff King [off-list ref] writes:
On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help