On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote: > 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. I think we're violently agreeing. Taking all of those inputs and computing the final value for a git-sequence editor is exactly what "git var" should be doing. IMHO it is a bug that when GIT_SEQUENCE_EDITOR was introduced, there was not a matching update to compute it from "git var" (I didn't even know sequence.editor existed until now!). I am not opposed to that at all; that's the point of "git var", and the "computables" we are talking about. I am only opposed to mixing the namespace for computables with config. I.e., there is no point in asking "git var" for the core.editor config. It is not a computable value, and we already have a way of accessing it (git-config, which can also _write_ the value, something that git-var will never be able to do for computable values). > > 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. 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. 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. -Peff -- 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