On Tue, Dec 2, 2014 at 8:04 AM, Jeff King <p...@peff.net> wrote: > On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote: > >> On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano <gits...@pobox.com> wrote: >> > >> > If I were redoing this today, I would probably nominate the "git" >> > potty as such a "kitchen synk" command. We have "--man-path" that >> > shows the location of the manual pages, "--exec-path[=path]" that >> > either shows or allows us to override the path to the subcommands, >> > and "--show-prefix", "--show-toplevel", and friends may feel quite >> > at home there. >> >> I wonder if we could reuse "git config" which is already a "kitchen >> synk" command to get/set a lot of parameters. >> Maybe we could dedicate a "git" or "virtual" or "proc" or "sys" (like >> /proc or /sys in Linux) namespace for these special config parameters >> that would not necessarily reflect something in the config file. >> >> "git config git.man-path" would be the same as "git --man-path". >> "git config git.root" would be the same as "git rev-parse --show-toplevel". >> "git config git.exec-path mypath" would allow us to override the path >> to the subcommands, probably by saving something in the config file. > > What would: > > git config git.root foo
That would output an error message saying that we cannot change the git.root value. > git config git.root That would output the same as "git rev-parse --show-toplevel". > output? No matter what the answer is, I do not relish the thought of > trying to explain it in the documentation. :) Yeah, maybe it is better if we don't reuse "git config". > There is also "git var", which is a catch-all for printing some deduced > environmental defaults. I'd be just as happy to see it go away, though. Yeah, maybe we could use "git var" for more variables. > Having: > > git --exec-path > git --toplevel > git --author-ident > > all work would make sense to me (I often get confused between "git > --foo" and "git rev-parse --foo" when trying to get the exec-path and > git-dir). And I don't think it's too late to move in this direction. > We'd have to keep the old interfaces around, of course, but it would > immediately improve discoverability and consistency. I don't like reusing the git command for that puropose, because it clutters it and makes it difficult to improve. For example let's suppose that we decide to have a "git info" command. It could work like this: $ git info sequence.editor vim $ git info core.editor emacs $ git info --verbose sequence.editor sequence.editor = vim GIT_EDITOR = emacs core.editor = nano $ git info --verbose core.editor GIT_EDITOR = emacs core.editor = nano So the --verbose option could explain why the sequence.editor is vim by displaying the all the relevant options with their values from the most important to the least important. Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
