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