git config：列出所有变量及其默认值
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/33720397/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
git config: list all variables and their default values
提问by Harry
Similar to the MySQL show variablescommand that shows all variables and not just the ones defined in my.ini, I would like to see a list of allconfig variables in gitalong withtheir default values, and not just those defined in my ~/.gitconfig.
类似于MySQL的show variables命令，显示所有变量，不只是在中定义的my.ini，我想看看清单所有在配置变量git连同它们的默认值，而不仅仅是那些在我的定义~/.gitconfig。
Is this possible?
这可能吗？
回答by VonC
Update May 2018: git help -c, as noted in Petr's answer.
2018 年 5 月更新：git help -c如Petr的回答中所述。
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.
在 Git 2.19（2018 年第二季度）中，继续以编程方式枚举命令行完成所需的各种数据的想法，教导代码库报告子命令关心的配置变量列表，以帮助完成它们。
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)
见提交f22f682（2018年5月27日），并提交09c4ba4，提交bea2125，提交f45db83，提交e17ca92，提交431bb23，提交fb6fbff，提交a4a9cc1，提交3ac68a9，提交a46baac，提交fa151dc，提交a73b368通过（2018年5月26日）Nguy？ n Thái Ng?c Duy ( pclouds)。
请参阅Junio C Hamano() 的commit 17b3e51（2018 年 5 月 29 日）。（由Junio C Hamano合并-- --在gitstergitster提交 ebaf0a5，2018 年 6 月 25 日）
help: add--configto list all available configSigned-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.
help: 添加--config以列出所有可用的配置签字人：Nguy?n Thái Ng?c Duy
有时它有助于列出所有可用的配置变量，以便用户可以搜索他们想要的东西。也可以使用配置手册页，但例如，如果您想专注于变量名称，则很难搜索。
这不是收集可用配置的最佳方式，因为它不精确。理想情况下，我们应该在 C 代码中有一个集中的配置列表（非常像“结构选项”），但这需要做更多的工作。这暂时就可以了。
Original answer: 2015
原答案：2015
That was debated in this thread in 2013, requested by Sebastian Schuberth, Jeff King (Peff)adding:
2013 年，在Sebastian Schuberth 的要求下，这个帖子中对此进行了辩论，Jeff King ( Peff)补充说：
The expected output is certainly a problem, but the issue is more fundamental than that:
git configdoes not even knowwhat 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 thathttp.receivepackconsiders "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).
预期的输出当然是一个问题，但问题比这更根本：
git config甚至不知道任何给定选项的默认值是什么。假设调用者知道如何处理未设置的值。而这与
git config; 内部 C 代码的工作方式相同。
在实际的默认值甚至不需要通过配置表达。
例如，我知道将http.receivepack“unset”视为不同的“true”或“false”，但设置它只能产生后两个值之一。
我敢肯定还有其他人（我这周刚好注意到那个）。
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.
我当然可以看到一个论点，即如果代码有一个包含选项及其描述、可能值和默认值的大表，并且如果我们使用它来生成文档以及验证输入，那么世界会变得更美好。
但是没有人不厌其烦地构建该表并转换所有调用者。正如Jakub (Jakub Nar?bski) 所提到的，这样的中央表对于将其配置与 git 一起存储的外部程序无能为力。
In short:
简而言之：
git configdoes 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.
git config甚至不知道它管理的任何选项或值，而只是一个“愚蠢的”前端，可以写入/读取您将其传递到/从文件中传递的任何内容。
Note: git config was introduced in commit 1771299 (git 0.99.9a, Oct. 2005)
注意：git config 是在commit 1771299中引入的（git 0.99.9a，2005 年 10 月）
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.
不同的程序可以对不同的配置选项做出反应，尽管它们应该始终回退到在它们不识别的任何配置选项名称上调用“git_default_config()”。
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:
所以在内部，有一种方法可以加载默认配置，最近使用的是相同的 Peff提交 72549df, git 2.2.0-rc1, Nov. 2014：
When we start the git-fetch program, we call git_config to load all config, but our callback only processes the
fetch.pruneoption; we do not chain togit_default_configat 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
当我们启动 git-fetch 程序时，我们调用 git_config 来加载所有的配置，但是我们的回调只处理
fetch.prune选项；我们根本不链接git_default_config。这意味着我们可能不会加载一些会产生影响的核心配置。例如，我们不加载
core.logAllRefUpdates，这会影响我们是否在裸存储库中创建引用日志。让我们在 fetch 开始时加载核心配置，所以我们知道我们已经有了它
See another example with commit 3e1dd17, git 1.7.7-rc1, Aug. 2011with the default color config.
查看另一个示例，提交 3e1dd17，git 1.7.7-rc1，2011 年 8 月，使用默认颜色配置。
回答by Matteo Meil
git config --global -lfor global variables or git config -lfor local repository variables
git config --global -l对于全局变量或git config -l本地存储库变量
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.
PS：我知道自您发布问题以来已经过去了 2 年，但我一直在寻找相同的东西并且我阅读了这篇文章所以我猜像我这样的用户会想要解决他们的问题并且我发布了回复，即使您可能很久以前就解决了您的问题。
回答by YenForYang
This method won't get you yoursettings along withthe 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,
或者如果你没有svn，
curl -L https://api.github.com/repos/git/git/tarball/master | tar -xvzf- --strip-components=1 --wildcards --no-anchored '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.
现在我们grep。我有 2 个版本：一个详细的，一个更紧凑的（可能缺少细节）。为了（某些）清楚起见，下面使用了长标志名称。
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
对于更“详细”的版本，只需将--regexp=标志更改为
(?ms)(?:^[a-zA-Z0-9]{2,}\.[<>()*.a-zA-Z -]+::\v+)+?(?:\v|\h+\V+\v)+(?:\+\v+(?:--\v+.+?--|[^+]\V+(?!::\v))+)*(?:\v|\Z)
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).
并且由于这完全基于正则表达式提取，因此不言而喻，这可能有一天会中断（例如，如果他们更改配置文档格式以使其不依赖于asciidoctor）。
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 `25` 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.
回答by Petr
If you have git 2.19 or newer
如果你有 git 2.19 或更新版本
git help -c
Will list all known keys that can be used for configuration
将列出可用于配置的所有已知密钥
