git config: list all variables and their default values

Question

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?

Answer 1

Edit Jan 23, 2022

• git config --system -l for system-wide variables (retrieved from installation folder; references)

• git config --global -l for global variables (retrieved from ~/.gitconfig or $XDG_CONFIG_HOME/git/config if the first doesn't exists; references)

• git config --local -l or git config -l for repository variables (retrieved from .git/config; references)

Also note that although on docs it says

--local [...] This is the default behavior.

issuing git config -l --local shows a different result than git config -l, the latter (apparently) showing all the three command outputs merged (tested on Windows)

---

Old answer

git config --global -l for global variables or git config -l for local repository variables

P.S.: I know have passed 2 years since you posted the question, but I was looking for the same thing and I read this post so I guessed users like me would have wanted a solution to their problem and I posted a reply, even if you probabily have solved your problem long time ago.

Answer 2

Update May 2018: git help -c, as noted in Petr's answer.

With Git 2.19 (Q2 2018), continuing with the idea to programatically enumerate various pieces of data required for command line completion, teach the codebase to report the list of configuration variables subcommands care about to help complete them.

See commit f22f682 (27 May 2018), and commit 09c4ba4, commit bea2125, commit f45db83, commit e17ca92, commit 431bb23, commit fb6fbff, commit a4a9cc1, commit 3ac68a9, commit a46baac, commit fa151dc, commit a73b368 (26 May 2018) by Nguyễn Thái Ngọc Duy (pclouds).
See commit 17b3e51 (29 May 2018) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit ebaf0a5, 25 Jun 2018)}

help: add --config to list all available config

^{Signed-off-by: Nguyễn Thái Ngọc Duy}

Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example.

This is not the best way to collect the available config since it's not precise. Ideally we should have a centralized list of config in C code (pretty much like 'struct option'), but that's a lot more work. This will do for now.

---

Strangely enough, this is formelly documented only with Git 2.34 (Q4 2021).

See commit ae578de (13 Sep 2021) by Philip Oakley (PhilipOakley).
^{(Merged by Junio C Hamano -- gitster -- in commit 68658a8, 23 Sep 2021)}

doc: config, tell readers of git help --config

^{Signed-off-by: Philip Oakley}

git config now includes in its man page:

A list of all available configuration variables can be obtained using the git help --config command.

---

Original answer: 2015

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.

---

Completion can help too seeing a list of all config variables in git :

With Git 2.34 (Q4 2021), teach "git help -c"^(man) into helping the command line completion of configuration variables.

See commit 06fa4db, commit a9baccc, commit 5a5f04d, commit d35d03c, commit 0a5940f, commit 1ed4bef, commit ff76fc8, commit 9856ea6 (22 Sep 2021), and commit b408452 (10 Sep 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 62f035a, 13 Oct 2021)}

help / completion: make "git help" do the hard work

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

The "help" builtin has been able to emit configuration variables since e17ca92 ("completion: drop the hard coded list of config vars", 2018-05-26, Git v2.19.0-rc0 -- merge listed in batch #1), but it hasn't produced exactly the format the completion script wanted.
Let's do that.

We got partway there in 2675ea1 ("completion: use 'sort -u' to deduplicate config variable names", 2019-08-13, Git v2.24.0-rc0 -- merge listed in batch #3) and d943887 ("completion: deduplicate configuration sections", 2019-08-13, Git v2.24.0-rc0 -- merge listed in batch #3), but after both we still needed some sorting, de-duplicating and awk post-processing of the list.

We can instead simply do the relevant parsing ourselves (we were doing most of it already), and call string_list_remove_duplicates() after already sorting the list, so the caller doesn't need to invoke "sort -u".
The "--config-for-completion" output is the same as before after being passed through "sort -u".

Then add a new "--config-sections-for-completion" option.
Under that output we'll emit config sections like "alias" (instead of "alias." in the --config-for-completion output).

We need to be careful to leave the "--config-for-completion" option compatible with users git, but are still running a shell with an older git-completion.bash.
If we e.g. changed the option name they'd see messages about git-completion.bash being unable to find the "--config-for-completion" option.

Such backwards compatibility isn't something we should bend over backwards for, it's only helping users who:

• Upgrade git
• Are in an old shell
• The git-completion.bash in that shell hasn't cached the old "--config-for-completion" output already.

But since it's easy in this case to retain compatibility, let's do it, the older versions of git-completion.bash won't care that the input they get doesn't change after a "sort -u".

While we're at it let's make "--config-for-completion" die if there's anything left over in "argc", and do the same in the new "--config-sections-for-completion" option.

---

With Git 2.43 (Q4 2023), git cmd -h learned to signal which options can be negated by listing such options like --[no-]opt".

See commit 311c8ff, commit 2a409a1, commit 652a6b1, commit e8e5d29, commit d5dc68f, commit 8dcb490, commit aa43619, commit d716512 (05 Aug 2023) by René Scharfe (rscharfe).
^{(Merged by Junio C Hamano -- gitster -- in commit 6d159f5, 25 Aug 2023)}

parse-options: show negatability of options in short help

^{Signed-off-by: René Scharfe}

Add a "[no-]" prefix to options without the flag PARSE_OPT_NONEG to document the fact that you can negate them.

This looks a bit strange for options that already start with "no-", e.g. for the git option --no-name of show-branch:

--[no-]no-name        suppress naming strings

You can actually use --no-no-name as an alias of --name, so the short help is not wrong.
If we strip off any of the "no-"s, we lose either the ability to see if the remaining one belongs to the documented variant or to see if it can be negated.

git rev-parse now includes in its man page:

--[no-]foo            some nifty option --foo
--[no-]bar ...        some cool option --bar with an argument
--[no-]baz <arg>      another cool option --baz with a named argument
--[no-]qux[=<path>]   qux may take a path argument but has meaning by itself

Answer 3

If you have git 2.19 or newer

git help -c

Will list all known keys that can be used for configuration

Answer 4

This method won't get you your settings along with the defaults, but this is a pretty solid method of getting the documented settings (and their defaults, if documented):

First get the Documentation from the source repo

svn export https://github.com/git/git/trunk/Documentation

or if you don't have svn,

curl -L https://api.github.com/repos/git/git/tarball/master | tar -xvzf- --wildcards "*/Documentation/*"

Enter the directory

cd Documentation

Now we grep. I have 2 versions: one detailed, and one more compact (likely missing details). Long flag names are used below for (some) clarity.

First the compact version:

grep --recursive                    \
    --binary-files=without-match    \
    --no-filename                   \
    --only-matching                 \
    --perl-regexp                   \
    --null-data                     \
    --regexp='(?ms)(?:^[a-zA-Z0-9]{2,}\.[<>()*.a-zA-Z -]+::\v+)+?(?:(?:\v|\h+\V+\v))+(?:\v|\Z)' 

For the more 'detailed' version simply change the --regexp= flag to

(?ms)(?:^[a-zA-Z0-9]{2,}\.[<>()*.a-zA-Z -]+::\v+)+?(?:\v|\h+\V+\v)+(?:\+\v+(?:--\v+.+?--|[^+]\V+(?!::\v))+)*(?:\v|\Z)

Debuggex Demo

And since this is all based on regex extraction, it goes without saying that this may break someday (if they change the config documentation formatting so that it doesn't rely on asciidoctor, for example).

Some sample output--note that not all of them have default values:

core.hideDotFiles::
        (Windows-only) If true, mark newly-created directories and files whose
        name starts with a dot as hidden.  If 'dotGitOnly', only the `.git/`
        directory is hidden, but no other files starting with a dot.  The
        default mode is 'dotGitOnly'.

 core.precomposeUnicode::
        This option is only used by Mac OS implementation of Git.
        When core.precomposeUnicode=true, Git reverts the unicode decomposition
        of filenames done by Mac OS. This is useful when sharing a repository
        between Mac OS and Linux or Windows.
        (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).
        When false, file names are handled fully transparent by Git,
        which is backward compatible with older versions of Git.

 core.protectHFS::
        If set to true, do not allow checkout of paths that would
        be considered equivalent to `.git` on an HFS+ filesystem.
        Defaults to `true` on Mac OS, and `false` elsewhere.

 core.protectNTFS::
        If set to true, do not allow checkout of paths that would
        cause problems with the NTFS filesystem, e.g. conflict with
        8.3 "short" names.
        Defaults to `true` on Windows, and `false` elsewhere.

 core.fsmonitor::
        If set, the value of this variable is used as a command which
        will identify all files that may have changed since the
        requested date/time. This information is used to speed up git by
        avoiding unnecessary processing of files that have not changed.
        See the "fsmonitor-watchman" section of linkgit:githooks[5].

 core.trustctime::
        If false, the ctime differences between the index and the
        working tree are ignored; useful when the inode change time
        is regularly modified by something outside Git (file system
        crawlers and some backup systems).
        See linkgit:git-update-index[1]. True by default.

 core.splitIndex::
        If true, the split-index feature of the index will be used.
        See linkgit:git-update-index[1]. False by default.

 core.untrackedCache::
        Determines what to do about the untracked cache feature of the
        index. It will be kept, if this variable is unset or set to
        `keep`. It will automatically be added if set to `true`. And
        it will automatically be removed, if set to `false`. Before
        setting it to `true`, you should check that mtime is working
        properly on your system.
        See linkgit:git-update-index[1]. `keep` by default.

 core.quotePath::
        Commands that output paths (e.g. 'ls-files', 'diff'), will
        quote "unusual" characters in the pathname by enclosing the
        pathname in double-quotes and escaping those characters with
        backslashes in the same way C escapes control characters (e.g.
        `\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with
        values larger than 0x80 (e.g. octal `\302\265` for "micro" in
        UTF-8).  If this variable is set to false, bytes higher than
        0x80 are not considered "unusual" any more. Double-quotes,
        backslash and control characters are always escaped regardless
        of the setting of this variable.  A simple space character is
        not considered "unusual".  Many commands can output pathnames
        completely verbatim using the `-z` option. The default value
        is true.

Caveats:

• Deprecated config options like versionsort.prereleaseSuffix and add.ignore-errors are not targeted and will probably not be picked up.
• Type II errors (false negatives) are not eliminated. To get all possible config key names along with their respective file location, try:

  grep --recursive --binary-files=without-match --only-matching --perl-regexp --regexp='^([^-'"'"'</[ ]+\.|\t+)[a-zA-Z0-9-<>_\*]+(?=::$)'
  

  There will probably be false positives in this case, however.