git config:列出所有变量及其默认值

73
与 MySQL 的 show variables 命令类似,它显示所有变量而不仅仅是在my.ini 中定义的变量,我想要看到 git所有配置变量列表及其默认值,而不仅仅是在我的 ~/.gitconfig 中定义的变量。是否可能?

13
你是否正在寻找“git config --list”命令?否则,VonC已经回答了你的问题。 - rajuGT
15
@rajuGT 我认为 git config --list 不是 Harry 寻找的,因为它只会返回在系统、全局或本地级别明确设置的配置,而不是所有其他未设置的设置及其默认值。 - VonC
4个回答

51

2022年1月23日编辑

  • git config --system -l获取系统范围内的变量(从安装文件夹中检索; 参考文献

  • git config --global -l获取全局变量(从~/.gitconfig$XDG_CONFIG_HOME/git/config(如果第一个不存在)的位置进行检索; 参考文献

  • 对于存储库变量,使用git config --local -lgit config -l进行检索(从.git/config中检索; 参考文献

请注意,尽管文档上说

--local [...] 这是默认行为。

但发出 git config -l --local 命令显示的结果与 git config -l 不同,后者(显然)显示了所有三个命令的输出合并后的结果(在 Windows 上进行测试)。


旧回答

git config --global -l 获取全局变量或 git config -l 获取本地存储库变量

P.S .:我知道您发布问题已经过去了2年,但我正在寻找同样的东西,并阅读了这篇文章,所以我猜想像我这样的用户会希望解决他们的问题,因此我发表了回复,即使您可能很久以前已经解决了问题。


42
这不是这个问题的答案。无论是否设置,原帖作者肯定想知道所有选项。虽然问题没有明确说明,但可以从他想看到默认值的愿望中推断出来。请参见[VonC](https://stackoverflow.com/users/6309/vonc)在问题下面的评论。 - Tobias
3
哦,我误解了问题。 在我回答中写的时候,我正在寻找这些命令,所以我认为哈利想知道这个,但显然我错了。我的唯一意图是帮助其他想要寻找同样内容的人。 - Matteo Meil

49
2018年5月更新:如Petr答案中所提到的,使用git help -c命令。
随着Git 2.19(2018年第二季度)的推出,继续以编程方式枚举命令行完成所需的各种数据的思路,教会代码库报告配置变量子命令关心的列表,以帮助完成它们。
查看commit f22f682(2018年5月27日),以及commit 09c4ba4commit bea2125commit f45db83commit e17ca92commit 431bb23commit fb6fbffcommit a4a9cc1commit 3ac68a9commit a46baaccommit fa151dccommit a73b368(2018年5月26日)由Nguyễn Thái Ngọc Duy (pclouds)完成。
查看commit 17b3e51(2018年5月29日)由Junio C Hamano (gitster)完成。
(由Junio C Hamano -- gitster --合并于commit ebaf0a5,2018年6月25日)

help:添加--config以列出所有可用的配置

签名:Nguyễn Thái Ngọc Duy

有时候列出所有可用的配置变量可以帮助用户查找他们想要的内容。也可以使用配置手册,但如果您想专注于变量名称进行搜索,则会更加困难。

这不是收集可用配置的最佳方式,因为它不够精确。理想情况下,我们应该在C代码中拥有一个集中的配置列表(类似于“struct option”),但这需要更多的工作。暂时先这样吧。


奇怪的是,这只有在Git 2.34(2021年第四季度)中正式记录下来。
请参阅提交 ae578de(2021年9月13日),作者为Philip Oakley(PhilipOakley
(由Junio C Hamano -- gitster --合并于提交 68658a8,2021年9月23日)

doc:配置,告诉读者如何使用git help --config

签名:Philip Oakley

git config现在在其手册页面中包含以下内容:

可以使用git help --config命令获取所有可用的配置变量列表。


原始答案:2015

这在2013年的这个帖子中进行了讨论,由Sebastian Schuberth提出请求,Jeff King(Peff补充说:

预期的输出确实是一个问题,但问题比这更基本:git config甚至不知道任何给定选项的默认值。
假设调用者知道如何处理未设置的值。而且这与git config无关;内部C代码的工作方式也是一样的。 实际的默认值甚至不一定可以通过配置表达出来。 例如,我知道http.receivepack将"unset"视为与"true"或"false"不同的值,但设置它只能产生这两个后者的一个值。 我相信还有其他类似的情况(我刚好在本周注意到了这个)。
(例如:gc.prune)
我完全可以理解这样一个观点:如果代码中有一个包含选项及其描述、可能的取值和默认值的大表格,并且我们使用它来生成文档并验证输入,那么世界将会变得更美好。但是没有人费心去构建这个表格并转换所有的调用者。正如Jakub (Jakub Narębski)所提到的,这样一个中央表格对于将配置存储在git旁边的外部程序毫无作用。
简而言之: git config甚至不知道它管理的任何选项或值,只是一个“愚蠢”的前端,用于将您传递给它的内容写入/读取文件。
注意:git config是在commit 1771299 (git 0.99.9a, Oct. 2005)中引入的。
不同的程序可以对不同的配置选项做出反应,尽管它们应该始终回退到对任何未识别的配置选项名称调用"git_default_config()"。
因此,在内部有一种加载默认配置的方法,最近由同一位Peff在commit 72549df, git 2.2.0-rc1, Nov. 2014中使用。
当我们启动git-fetch程序时,我们调用git_config加载所有配置,但是我们的回调函数只处理fetch.prune选项;我们根本不链接到git_default_config。
这意味着我们可能没有加载某些核心配置,这将产生影响。例如,我们没有加载core.logAllRefUpdates,这会影响是否在裸仓库中创建reflogs。
让我们在fetch开始时只加载核心配置,这样我们就知道我们拥有它。
请参考另一个例子commit 3e1dd17, git 1.7.7-rc1, Aug. 2011中的默认颜色配置。
完成还可以帮助查看Git中所有配置变量的列表:
在Git 2.34(2021年第四季度)中,教会"git help -c"(man)来帮助命令行自动完成配置变量。
查看提交 06fa4db提交 a9baccc提交 5a5f04d提交 d35d03c提交 0a5940f提交 1ed4bef提交 ff76fc8提交 9856ea6(2021年9月22日),以及提交 b408452(2021年9月10日)由Ævar Arnfjörð Bjarmason(avar
(由Junio C Hamano -- gitster --合并于提交 62f035a,2021年10月13日)

帮助/完成:让"git help"来做艰苦的工作

签名:Ævar Arnfjörð Bjarmason

"help"内置命令自e17ca92(“completion: drop the hard coded list of config vars”,2018-05-26,Git v2.19.0-rc0 -- merge listed in batch #1)以来就能够输出配置变量,但它的输出格式并不完全符合补全脚本的要求。 我们来解决这个问题。
2675ea1(“completion: use 'sort -u' to deduplicate config variable names”,2019-08-13,Git v2.24.0-rc0 -- merge listed in batch #3)和d943887(“completion: deduplicate configuration sections”,2019-08-13,Git v2.24.0-rc0 -- merge listed in batch #3)中,我们已经完成了部分工作,但在这之后仍然需要对列表进行排序、去重和awk后处理。
相反,我们可以自己进行相关的解析(我们已经做了大部分工作),并在对列表进行排序后调用string_list_remove_duplicates(),这样调用者就不需要再调用“sort -u”了。 经过“sort -u”处理后,“--config-for-completion”输出与之前相同。
然后添加一个新的“--config-sections-for-completion”选项。 在该输出下,我们将输出类似于“alias”(而不是在--config-for-completion输出中的“alias.”)的配置节。
我们需要小心保持“--config-for-completion”选项与用户的git兼容,但仍然在使用旧版git-completion.bash的shell中运行。 例如,如果我们更改了选项名称,他们会看到关于git-completion.bash无法找到“--config-for-completion”选项的消息。
这种向后兼容性并不是我们必须费尽心思去做的,它只有帮助以下用户才有意义: - 升级了git - 使用旧版本的shell - 该shell中的git-completion.bash尚未缓存旧的“--config-for-completion”输出。
但由于在这种情况下保持兼容性很容易,让我们这样做吧,旧版本的git-completion.bash不会在“sort -u”之后对其输入是否发生变化感到在意。
顺便说一句,让我们使“--config-for-completion”在“argc”中还有剩余内容时终止,并在新的“--config-sections-for-completion”选项中也做同样的处理。
从Git 2.43(2023年第四季度)开始,git cmd -h 学会了通过列出可否定的选项来表示这些选项,例如 --[no-]opt
查看提交 311c8ff, 提交 2a409a1, 提交 652a6b1, 提交 e8e5d29, 提交 d5dc68f, 提交 8dcb490, 提交 aa43619, 提交 d716512 (2023年8月5日) 由René Scharfe (rscharfe)完成。
(由Junio C Hamano -- gitster --合并于提交 6d159f5, 2023年8月25日) parse-options:在简短的帮助信息中显示选项的否定性 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现在在其手册页中包含了:

--[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

1
我不确定其中所提出的论点是否成立,因为新的标志/选项总是可以添加而不会引起向后兼容性问题。但是感谢您指向这个线程! - Harry
1
@Harry 我不认为这是兼容性问题,但正如我刚才在答案中编辑的那样,git config 只存在于读取配置文件,而不知道任何关于 git 设置的信息。 - VonC
@VonC 是的吗?我看到了一个关于“是否无法通过编程方式查看它们”的问题? - VonC

11

如果您拥有 Git 2.19 或更新版本

git help -c

列出所有已知可用于配置的键


1
如果您更喜欢长格式以获得更清晰的信息,也可以使用 git help --config - Freedom_Ben

6

这种方法不能获取你的设置和默认设置,但这是一种获得记录的设置(如果有文档)的非常可靠的方法:

首先从源代码库中获取文档。

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

如果您没有 svn

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

进入目录

cd Documentation

现在我们使用grep命令。我有2个版本:一个详细版本和一个简洁版本(可能缺少一些细节)。下面使用长标志名称(某些)更清晰明了。
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)' 

如果需要更详细的版本,只需将--regexp=标志更改为

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

正则表达式可视化

Debuggex演示

由于这全部基于正则表达式提取,所以不用说,如果他们改变配置文档格式使其不再依赖于asciidoctor,它可能会在某些时候出现问题。

一些样本输出--请注意,并非所有输出都有默认值:

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.

注意事项:

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

3
这真的很棒,谢谢!Mac用户提示:您需要GNU版本的grep,请使用Homebrew进行安装,使用 brew install grep,然后将上述 grep 替换为 ggrep。 另外,为了更清晰--您将使用 cat <documentation_file_of_interest>.txt | ggrep <crazy_grep_command> - Luke Davis
4
除了在线获取文档外,git help config 也提供了文档。 - user202729

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接