git配置:列出所有变量及其默认值 - git config: list all variables and their default values

- 此内容更新于:2016-02-03



Similar to the MySQL show variables command that shows all variables and not just the ones defined in my.ini, I would like to see a list of all config variables in git along with their default values, and not just those defined in my ~/.gitconfig.

Is this possible?


(原文:are you looking for git config --list command? else VonC post answers to your question.)


(原文:@rajuGT I don't think git config --list is what Harry is looking for, since it would only return the config explicitly set at system, global or local level, and not all the other settings not set, with their default values.)


That was debated in this thread in 2013, requested by Sebastian Schuberth, Jeff King (Peff) adding:

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

(For instance: gc.prune)

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 (Jakub Narębski) mentioned, such a central table can do nothing for external programs that store their config alongside git's.

In short:

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.

Note: git config was introduced in commit 1771299 (git 0.99.9a, Oct. 2005)

Different programs can react to different config options, although they should always fall back to calling "git_default_config()" on any config option name that they don't recognize.

So internally, there is a way to load default config, used as recently as commit 72549df, git 2.2.0-rc1, Nov. 2014, by the same Peff:

When we start the git-fetch program, we call git_config to load all config, but our callback only processes the fetch.prune option; we do not chain to git_default_config at all.

This means that we may not load some core configuration which will have an effect. For instance, we do not load core.logAllRefUpdates, which impacts whether or not we create reflogs in a bare repository.

Let's just load the core config at the start of fetch, so we know we have it

See another example with commit 3e1dd17, git 1.7.7-rc1, Aug. 2011 with the default color config.


(原文:Not sure if I buy the arguments presented in there, as a new flag/option can always be added without raising backward compatibility concerns. But +1 for pointing me to the thread!)


(原文:@Harry I don't think it is a compatibility problem, but, as I just edited in the answer, the fact that git config is only there to read config files, not to know anything about git settings.)