Re: [PATCH] introduce git root

[Jeff King <peff@peff.net>]

On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > 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.
> 
> Yeah, I too think the above makes sense.  I forgot about "var", but
> it should go at the same time we move kitchen-sink options out of
> "rev-parse".  One less command to worry about at the UI level means
> you do not have to say "if you want to learn about X, ask 'var', if
> you want to learn about Y, ask 'rev-parse', use 'git' itself for Z".

Christian raised the issue of cluttering the "git --option" namespace,
and I do agree that's a potential issue. My proposal was to drop "git
var", but I'd also be OK with making "git var" the new kitchen sink.  It
doesn't accept many options now, so it's fairly wide open for changing
without losing backwards compatibility. AFAICT, the "-l" option is
utterly useless, but other than that, it just takes a variable name. We
could introduce dashed options, or just define a sane variable namespace.

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).

-Peff