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

On 14 April 2013 22:34, Sebastian Schuberth [off-list ref] 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

On Sun, Apr 14, 2013 at 2:47 PM, Andrew Ardill [off-list ref] wrote:

On 14 April 2013 22:34, Sebastian Schuberth [off-list ref] wrote:

quoted

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

On 14 April 2013 22:56, Sebastian Schuberth [off-list ref] wrote:

quoted

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

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

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

On Sun, Apr 14, 2013 at 8:56 PM, Jeff King [off-list ref] wrote:

quoted

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