Why does git config output nothing instead of the default value for unset variables?
Hi, I'm just wondering why it was decided to work like this. IMHO it's quite inconvenient that git config outputs nothing for any unset (but known) variable. Usually when I query a variable I'm not so much interested in whether it is at all (explicitly) set to some value or not, but what value is currently in use. With that in mind, it would make much more sense for git config to print the implicit default value instead of nothing if a known variable is unset. For unknown / custom variables it still could display nothing, which also gives a nice way to check whether a given variable name is known to Git or not. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
On 14 April 2013 22:34, Sebastian Schuberth sschube...@gmail.com wrote: Usually when I query a variable I'm not so much interested in whether it is at all (explicitly) set to some value or not, but what value is currently in use. With your change in place, how do you know if the config item has been explicitly set in your system? The closest thing I can see for doing this is git config --list, but perhaps there should be a flag to check if a config item is set? 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. Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
On Sun, Apr 14, 2013 at 2:47 PM, Andrew Ardill andrew.ard...@gmail.com wrote: On 14 April 2013 22:34, Sebastian Schuberth sschube...@gmail.com wrote: Usually when I query a variable I'm not so much interested in whether it is at all (explicitly) set to some value or not, but what value is currently in use. With your change in place, how do you know if the config item has been explicitly set in your system? Well, this could be done several ways. Maybe output the variable value in all upper case if it's the implicit / built-in default, and in all lower case if it has been explicitly set somewhere. The closest thing I can see for doing this is git config --list, but perhaps there should be a flag to check if a config item is set? Yet more command line options? Well, there's probably no way around that in order to maintain backward compatibility. 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. Right. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
On 14 April 2013 22:56, Sebastian Schuberth sschube...@gmail.com wrote: The closest thing I can see for doing this is git config --list, but perhaps there should be a flag to check if a config item is set? Yet more command line options? Well, there's probably no way around that in order to maintain backward compatibility. '--list' already exists; it shows all defined options. With your change in place (and no others) then the only (documented) way to know if something was configured would be by looking at git config --list. Changing the default behaviour is probably too big a breaking change, but a flag to change the behaviour might be nice. Then again, there may be away to do what you want already :-) Regards, Andrew Ardill -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
Sebastian Schuberth wrote: Hi, I'm just wondering why it was decided to work like this. IMHO it's quite inconvenient that git config outputs nothing for any unset (but known) variable. Usually when I query a variable I'm not so much interested in whether it is at all (explicitly) set to some value or not, but what value is currently in use. With that in mind, it would make much more sense for git config to print the implicit default value instead of nothing if a known variable is unset. For unknown / custom variables it still could display nothing, which also gives a nice way to check whether a given variable name is known to Git or not. I think git-config was meant to be git agnostic (and therefore usable outside git, and for files other that git config files). It would be better to add required functionality to git-var, IMHO. -- Jakub Narębski -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why does git config output nothing instead of the default value for unset variables?
On Sun, Apr 14, 2013 at 8:56 PM, Jeff King p...@peff.net 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. Thanks for the explanation, I feared something like that. I.e. that git config does not even know any of the options or values it manages, but just is a dumb front-end to writing / reading whatever you pass it to / from a file. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
