Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> 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. -- 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