On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 -- 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