Re: [PATCH] introduce git root

From: Christian Couder <christian.couder@gmail.com>
Date: Dec 7, 2014, 05:23 UTC
Message-ID: <CAP8UFD3mXJEHOfSoW6-B8uAR0gv2ZKWUhAs1SpNr17wVsRpM6g@mail.gmail.com>
In-Reply-To: <20141205092752.GC32112@peff.net>

On Fri, Dec 5, 2014 at 10:27 AM, Jeff King <peff@peff.net> wrote:

Show 21 quoted lines

> On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
>
>> > I do not think "git var --exec-path" is a good idea, nor GIT_EXEC_PATH
>> > for the environment-variable confusion you mentioned. I was thinking of
>> > just creating a new namespace, like:
>> >
>> >   git var exec-path
>> >   git var author-ident
>>
>> I agree that this is nice, but I wonder what we would do for the
>> sequence editor and the default editor.
>> Maybe:
>>
>> git var sequence-editor
>> git var editor
>
> Again, I think we're mostly agreeing. Context and hierarchy and falling
> back are good things. Whatever we call the variables, "editor" and
> "sequence-editor" and "foo-editor" should have a predictable and
> consistent form. I like the idea of "foo-editor" automatically falling
> back to "editor" even if we don't know what "foo" is.

Yeah but that means that we have to use something other than "-" to separate the context from the name, because we already have names like exec-path, html-path and man-path.

Show 19 quoted lines

> But the one place I do not agree is:
>
>> I think "sequence.editor" and "core.editor" are better because:
>>
>> - they use the same syntax as the config variables, so they are easier
>> to remember and to discover, and
>
> I really don't like using "core.editor" here, because it has the same
> name as a config variable, but it is _not_ the config variable. It
> happens to use the config variable as one of the inputs to its
> computation, but in many cases:
>
>   git config core.editor
>
> and
>
>   git var core.editor
>
> will produce different values.

Yeah, but I don't think it is a problem. They are different commands, so it can be expected that they do different things.

For example, if you use "git log origin/master" you get a different ouput than if you use "git show origin/master", though you still use the same "origin/master" notation.

When you use "git show" you consider only the commit pointed to by origin/master and when you use "git log" you consider the same commit but also all its ancestors.

In the same way, when you use "git config core.editor" you consider only the value of the core.editor logical variable in the config files, while when you would use "git var core.editor" you would consider the value of the core.editor logical variable in both the config files and the environment variables.

Show 5 quoted lines

> They are entirely different namespaces.
> Using the same syntax and name seems unnecessarily confusing to me. Even
> still using dotted hierarchies, but giving them different names (e.g.,
> "editor", "editor.sequence", "editor.foo") would make it more obvious
> that they are not the same thing.

Using yet another namespace or syntax when we could reuse an existing one is what would seem unnecessarily confusing to me. The value of the "editor" logical variable in the "sequence" context is related to the "sequence.editor" logical value in the config file, because the later can directly influence the former. So there is a reason to use the same notation.

Best, Christian.