Re: [PATCH] introduce git root

[Jeff King <peff@peff.net>]

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@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
  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