Re: Why does "git config" output nothing instead of the default value for unset variables?

[Jeff King <peff@peff.net>]

On Sun, Apr 14, 2013 at 10:47:31PM +1000, Andrew Ardill wrote:

> More to the point, I can easily imagine many scripts relying on git
> config returning a value to indicate that a config item has been set.
> Your proposed change would break all those. For that reason, it might
> be nicer to introduce a flag that returns the config if it is set or
> the default otherwise. Something like git config --value perhaps.

The expected output is certainly a problem, but the issue is more
fundamental than that: git-config does not even _know_ what the default
is for any given option.

It is assumed that the caller knows what to do with an unset value. And
this is nothing to do with git-config; the internal C code works the
same way. The actual defaults are not even necessarily expressible
through the config. E.g., I know that http.receivepack considers "unset"
to be distinct either "true" or "false", but setting it can yield only
one of those latter two values. I'm sure there are others, too (I just
happened to notice that one this week).

I could certainly see an argument that the world would be a better place
if the code had a big table of options and their descriptions, possible
values, and defaults, and if we used that to generate documentation as
well as validate input. But nobody has gone to the trouble to construct
that table and convert all of the callers. And as Jakub mentioned, such
a central table can do nothing for external programs that store their
config alongside git's.

So I think the desire that is expressed in this thread is reasonable,
but I don't see it happening anytime soon. I'd love to be proved wrong
by somebody converting the whole system, of course. :)

I'd also be fine with a "git config --get-$TYPE $OPTION $DEFAULT" mode;
the "--get-color" option already works like this. But the caller has
to provide the "$DEFAULT", since git-config does not know it. So I
suspect it defeats the purpose of the original request.

-Peff