Re: [PATCH] introduce git root

[Christian Couder <christian.couder@gmail.com>]

Jeff King <peff@peff.net> wrote:

> Some of the discussion has involved mixing config options into this
> kitchen sink, but that does not make any sense to me (and is why I
> find "git var -l" so odd). Config options are fundamentally different, in
> that they are set and retrieved, not computed (from other config
> variables, or from hard-coded values). And we already have a nice
> tool for working with them (well...nice-ish, let's say).

Yeah, but "git config" cannot say which config option applies in some
context and why.
For example, to chose the editor all the following could apply:

GIT_SEQUENCE_EDITOR env variable
sequence.editor config variable
GIT_EDITOR env variable
core.editor config variable
VISUAL env variable
EDITOR env variable
editor configured at compile time

and the user or our own scripts right now cannot easily know which
editor should be used when editing the sequence list.

The best they can do is:

- first check if GIT_SEQUENCE_EDITOR is set, and if yes, use it
- then check if sequence.editor config variable is set, and if yes, use it
- then use "git var GIT_EDITOR" that will check the other options

I don't think it is very nice.

Jeff King <peff@peff.net> also wrote:

> My issue is only that "git --foo" has other options besides computables.
> So you need to name each option in a way that makes it clear it is
> reporting a computable and not doing something else.
>
> Take "git --pager" for instance. That would be a natural choice to
> replace "git var GIT_PAGER". But shouldn't "--pager" be the opposite of
> the existing "--no-pager"?
>
> So instead we probably need some namespace to indicate that it is a
> "showing" option. Like "--show-pager". And then for consistency, we
> would probably want to move "--exec-path" to "--show-exec-path",
> creating a new "--show-" namespace. Or we could call that namespace
> "git var". :)

I agree with that, but I think it could be better if there was also a
notion of context,

> 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

That would already be nicer than what we have now, but maybe we should
consider the following instead:

git var sequence.editor
git var core.editor

(and maybe also some aliases to core.editor, like:

git var default.editor
git var editor)

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
- they provide a notion of context.

The notion of context is interesting because suppose that we later
introduce the "commit.editor" config variable. If we decide now that
"foo.editor" means just "core.editor" if we don't know about any
"editor" variable related to the "foo" context, then the scripts that
might later be written using "git var commit.editor" will not have to
worry about the fact that previous versions of Git didn't know about
"commit.editor".

People could even start using "git var commit.editor" now, because it
would work even if "commit.editor" is unused by git commit.

Of course when the user asks for "git var foo.editor" and we don't
know about any "editor" variable related to the "foo" context, we
first should check if "foo.editor" exists in the config file and we
should use that if it exists, before we default to "git var
core.editor".

Best,
Christian.