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 <gitster@xxxxxxxxx> 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 git config git.root output? No matter what the answer is, I do not relish the thought of trying to explain it in the documentation. :) 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. 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. -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