148

如何获得有关git / git-shell的调试信息？

我有一个问题，user1可以克隆一个存储库而没有问题，而user2只能克隆一个空的存储库。我已经准备好了GIT_TRACE=1，但是没有任何有用的信息。

最终，经过长时间的反复试验，结果证明这是文件的权限问题。适当的错误消息可能会使此问题短路。

git debugging trace

— 安多
source

注意：此外GIT_CURL_VERBOSE，您还将拥有Git 2.9.x / 2.10 GIT_TRACE_CURL。请参阅下面的答案。

— VonC

并且（2019年第二季度，三年后GIT_TRACE_CURL），您现在有了trace2。范例：git config --global trace2.normalTarget ~/log.normal。请参阅下面的我的（新）答案。

— VonC

212

要获得更详细的输出，请使用以下命令：

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master

— 世界贸易组织
source

53

除了核心选项之外，还有一些GIT_TRACE选项。这是über-verbose选项：

set -x; GIT_TRACE=2 GIT_CURL_VERBOSE=2 GIT_TRACE_PERFORMANCE=2 GIT_TRACE_PACK_ACCESS=2 GIT_TRACE_PACKET=2 GIT_TRACE_PACKFILE=2 GIT_TRACE_SETUP=2 GIT_TRACE_SHALLOW=2 git pull origin master -v -v; set +x

— Paul Irish

2

如何以及在何处设置此变量？

— 洪苏

您只需要整行就可以粘贴到终端中。您应该将git pull origin master零件替换为要执行的命令。

— Aeolun'3

1

此功能可在哪些平台上使用？当然不是Windows。

— cowlinator

8

在Windows上，您可以一次设置这些变量（每行一个），如下所示：set GIT_CURL_VERBOSE=1 set GIT_TRACE=1 git pull origin master

— cowlinator

85

调试

Git嵌入了相当完整的跟踪集，可用于调试git问题。

要打开它们，可以定义以下变量：

GIT_TRACE 对于一般痕迹，
GIT_TRACE_PACK_ACCESS 用于跟踪packfile访问，
GIT_TRACE_PACKET 用于网络操作的数据包级跟踪，
GIT_TRACE_PERFORMANCE 用于记录性能数据，
GIT_TRACE_SETUP 有关发现与之交互的存储库和环境的信息，
GIT_MERGE_VERBOSITY 用于调试递归合并策略（值：0-5），
GIT_CURL_VERBOSE用于记录所有curl消息（等效于curl -v），
GIT_TRACE_SHALLOW 用于调试浅层存储库的获取/克隆。

可能的值包括：

true，1或2写信给stderr，
/以跟踪输出到指定文件开头的绝对路径。

有关更多详细信息，请参见：Git内部-环境变量

SSH协议

对于SSH问题，请尝试以下命令：

echo 'ssh -vvv "$*"' > ssh && chmod +x ssh
GIT_SSH="$PWD/ssh" git pull origin master

或用于ssh验证您的凭据，例如

ssh -vvvT git@github.com

或通过HTTPS端口：

ssh -vvvT -p 443 git@ssh.github.com

^{注意：减少数量-v以降低详细程度。}

例子

$ GIT_TRACE=1 git status
20:11:39.565701 git.c:350               trace: built-in: git 'status'

$ GIT_TRACE_PERFORMANCE=$PWD/gc.log git gc
Counting objects: 143760, done.
...
$ head gc.log 
20:12:37.214410 trace.c:420             performance: 0.090286000 s: git command: 'git' 'pack-refs' '--all' '--prune'
20:12:37.378101 trace.c:420             performance: 0.156971000 s: git command: 'git' 'reflog' 'expire' '--all'
...

$ GIT_TRACE_PACKET=true git pull origin master
20:16:53.062183 pkt-line.c:80           packet:        fetch< 93eb028c6b2f8b1d694d1173a4ddf32b48e371ce HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2:2.6.5~update-ref-initial-update-1494-g76b680d
...

— Kenorb
source

2

在单个参数中包含空格的边缘情况下，更改echo 'ssh -vvv $*' > ssh && chmod +x ssh为echo 'ssh -vvv "$@"' > ssh && chmod +x ssh应该更安全。

— 亚历山大·伯德

46

试试这个：

GIT_TRACE=1 git pull origin master

— 抄送
source

40

如果通过SSH，则可以使用以下命令：

对于分别用于调试级别2和3的-vv或-vvv类型，获得更高的调试级别：

# Debug level 1
GIT_SSH_COMMAND="ssh -v" git clone <repositoryurl>

# Debug level 2
GIT_SSH_COMMAND="ssh -vv" git clone <repositoryurl>

# Debug level 3
GIT_SSH_COMMAND="ssh -vvv" git clone <repositoryurl>

这主要用于处理服务器的公钥和私钥问题。您可以将此命令用于任何git命令，而不仅限于“ git clone”。

— 罗勒穆萨
source

是的，这很完美。比别人好。是的，这很完美。比别人好。

— 宝马

这将是最有用的，因为我现在必须解决一个关键问题，但是它不适用于git 1.8.3.1和OpenSSH_6.6.1p1，OpenSSL 1.0.1e-fips（2013年2月11日）在CentOS Linux版本7.2.1511上（核心）。:(

— Greg Dubicki '16

@GregDubicki奇怪。让我知道什么对您有用，以便我更新答案。

— 罗勒·穆萨

1

在Windows上使用set GIT_SSH_COMMAND=ssh -v（无引号）。

— jansohn

18

Git 2.9.x / 2.10（2016年第三季度）添加了另一个调试选项：GIT_TRACE_CURL。

参见Elia Pinto（）的提交73e57aa，提交74c682d（2016年5月23日）。帮助对象：TorstenBögershausen（），Ramsay Jones，Junio C Hamano（），Eric Sunshine（）和Jeff King（）。^（由^{Junio C}^Hamano^合并^--^在^{commit 2f84df2中}^{，2016年7月6日）}devzero2000
tboegigitstersunshinecopeff
^gitster

http.c：实现GIT_TRACE_CURL环境变量

实现GIT_TRACE_CURL环境变量以允许更多的细节GIT_CURL_VERBOSE，尤其是完整的传输头和交换的所有数据有效载荷。
如果特定情况可能需要更彻底的调试分析，这可能会很有用。

该文档将说明：

GIT_TRACE_CURL

对git传输协议的所有传入和传出数据（包括描述性信息）启用curl完整跟踪转储。
这类似于在做curl --trace-ascii在命令行上执行。

此选项将覆盖设置GIT_CURL_VERBOSE环境变量。

您可以看到此答案中使用的新选项，还可以在Git 2.11（2016年第四季度）测试中看到：

请参见Elia Pinto（）的提交14e2411，提交81590bf，提交4527aa1，提交4eee6c6（2016年9月7日）。^{（通过合并}^{JUNIOÇ滨野-}^-^在^{提交930b67e}^{，2016年9月12日）}devzero2000
^gitster

使用新的GIT_TRACE_CURL环境变量而不是已弃用的 GIT_CURL_VERBOSE。

GIT_TRACE_CURL=true git clone --quiet $HTTPD_URL/smart/repo.git

— 冯
source

这个功能很酷！唯一的一点是ASCII输出（它们将所有未打印(ch >= 0x20) && (ch < 0x80)为dot的内容都打印出来.），并且无法对http数据进行十六进制输出。

— kinORnirvana

8

Git的2.22（Q2 2019）介绍trace2与承诺ee4512e由杰夫·霍斯泰特勒：

trace2：创建新的组合跟踪工具

为git创建一个新的统一跟踪工具。
最终的目的是为了取代目前trace_printf*并trace_performance*用一套统一的程序git_trace2*例程。

除了通常的printf样式的API外，trace2还提供具有固定字段的更高级别的事件动词，允许写入结构化数据。
这使得外部工具的后处理和分析更加容易。

Trace2定义了3个输出目标。
这些是使用环境变量“ GIT_TR2”，“ GIT_TR2_PERF”和“ GIT_TR2_EVENT”设置的。
这些可以设置为“ 1”或绝对路径名（就像current一样GIT_TRACE）。

注意：关于环境变量名称，请始终使用GIT_TRACExxx，而不要使用GIT_TRxxx。
所以实际上GIT_TRACE2，GIT_TRACE2_PERF还是GIT_TRACE2_EVENT。
请参阅下面稍后提到的Git 2.22重命名。

接下来是有关此新跟踪功能的初步工作，其中包含旧的环境变量名称：

GIT_TR2旨在替代GIT_TRACE命令并记录命令摘要数据。

GIT_TR2_PERF用于替代GIT_TRACE_PERFORMANCE。
它使用命令进程，线程，存储库，绝对和相对经过时间的列来扩展输出。它报告有关子进程启动/停止，线程启动/停止和每线程功能嵌套的事件。

GIT_TR2_EVENT是一种新的结构化格式。它将事件数据写为一系列JSON记录。

调用trace2函数将记录到启用的3个输出目标中的任何一个，而无需调用不同的trace_printf*或trace_performance*例程。

请参阅Josh Steadmon（）的 commit a4d3a28（2019年3月21日）。^（由^{Junio C}^Hamano^合并^--^在^{1b40314号提交中}^{，2019年5月8日）}steadmon
^gitster

trace2：写入目录目标

当trace2环境变量的值是引用现有目录的绝对路径时，请将输出写入给定目录下的文件（每个进程一个）。
文件将根据trace2 SID的最终组成部分命名，然后加上一个计数器以避免潜在的冲突。

通过无条件地将相关trace2envvar设置为常量目录名称，这使得为每次git调用收集跟踪更加方便。

另请参见Jeff Hostetler（）提交f672dee（2019年4月29日），提交81567ca，提交08881b9，提交bad229a，提交26c6f25，提交bce9db6，提交800a7f9，提交a7bc01e，提交39f4317，提交a089724，提交1703751（2019年4月15日）。^（由^{Junio C}^Hamano^合并^--^在^{commit 5b2d1c0中}^{，2019年5月13日）}jeffhostetler
^gitster

现在，新文档包括仅从系统和全局配置文件读取的配置设置（这意味着-c不遵守存储库本地和工作树配置文件以及命令行参数）。

范例：

$ git config --global trace2.normalTarget ~/log.normal
$ git version
git version 2.20.1.155.g426c96fcdb

产量

$ cat ~/log.normal
12:28:42.620009 common-main.c:38                  version 2.20.1.155.g426c96fcdb
12:28:42.620989 common-main.c:39                  start git version
12:28:42.621101 git.c:432                         cmd_name version (version)
12:28:42.621215 git.c:662                         exit elapsed:0.001227 code:0
12:28:42.621250 trace2/tr2_tgt_normal.c:124 atexit elapsed:0.001265 code:0

对于性能指标：

$ git config --global trace2.perfTarget ~/log.perf
$ git version
git version 2.20.1.155.g426c96fcdb

产量

$ cat ~/log.perf
12:28:42.620675 common-main.c:38                  | d0 | main                     | version      |     |           |           |            | 2.20.1.155.g426c96fcdb
12:28:42.621001 common-main.c:39                  | d0 | main                     | start        |     |  0.001173 |           |            | git version
12:28:42.621111 git.c:432                         | d0 | main                     | cmd_name     |     |           |           |            | version (version)
12:28:42.621225 git.c:662                         | d0 | main                     | exit         |     |  0.001227 |           |            | code:0
12:28:42.621259 trace2/tr2_tgt_perf.c:211         | d0 | main                     | atexit       |     |  0.001265 |           |            | code:0

如Git 2.23（Q3 2019）中所述，要使用的环境变量为GIT_TRACE2。

参见Carlo Marcelo ArenasBelón（）提交6114a40（2019年6月26日）。见提交3efa1c6由（2019年6月12日）ÆvarArnfjörðBjarmason（）。 ^（由^{Junio C}^Hamano^合并^--^在^{commit e9eaaa4中}^{，2019年7月9日）}carenas
avar
^gitster

这是SZEDERGábor（）在Git 2.22中完成的工作：commit 4e0d3aa，commit e4b75d6（2019年5月19日）。^（由^{Junio C}^Hamano^合并^--^在^{463dca6号提交中}^{，2019年5月30日）}szeder
^gitster

trace2：将环境变量重命名为GIT_TRACE2 *

对于应该由用户设置的环境变量， GIT_TR2* env var太不清楚，不一致和丑陋。

大部分既定的GIT_*环境变量，不要使用缩写，并且在那些（少数情况下GIT_DIR，GIT_COMMON_DIR，GIT_DIFF_OPTS）这是很明显的是什么的缩写（DIR和OPTS）代表。
但是代表什么TR呢？跟踪，传统，拖车，交易，转移，转换，过渡，翻译，移植，运输，遍历，树，触发器，截断，信任或...？！

trace2工具，正如其名称中的“ 2”后缀所示，应该最终取代Git的原始跟踪工具。
可以合理预期相应的环境变量也将效仿，并在原始GIT_TRACE变量之后调用它们GIT_TRACE2；没有这样的事情是GIT_TR '。

所有特定于trace2的配置变量都非常明智地位于' trace2'部分中，而不是' tr2'中。

OTOH，从这些环境变量的名称中省略了“ trace”的最后三个字符，我们一无所获。

因此，让我们将所有GIT_TR2*环境变量重命名为GIT_TRACE2*，然后再进入稳定版本。

Git 2.24（Q3 2019）改进了Git存储库的初始化。

请参阅Jeff King（）的提交22932d9，提交5732f2b和提交58ebccb（2019年8月6日）。^（由^{Junio C}^Hamano^合并^--^在^{commit b4a1eec中}^{，2019年9月9日）}peff
^gitster

common-main：延迟trace2初始化

我们使用trace2通用的main（）函数初始化系统，以便所有程序（甚至不是内置程序）都将启用跟踪。

但是trace2启动相对较重，因为我们必须实际读取磁盘配置来决定是否进行跟踪。
这可能会导致与其他公用主初始化的意外交互。例如，我们将在调用之前进入配置代码initialize_the_repository()，而通常的不变式是the_repository永远不会为NULL将不成立。

让我们trace2在common-main中进一步将初始化推到执行之前cmd_main()。

Git 2.24（2019年第四季度）还确保trace2现在子系统的输出格式更加简洁。

请参阅Jeff Hostetler（）提交的742ed63，提交e344305，提交c2b890a（2019年8月9日），提交ad43e37，提交04f10d3，提交da4589c（2019年8月8日）和提交371df1b（2019年7月31日）。^（由^{Junio C}^Hamano^合并^--^在^{commit 93fc876中}^{，2019年9月30日）}jeffhostetler
^gitster

而且，仍然是Git 2.24

请参阅Josh Steadmon（）的提交87db61a，提交83e57b0（2019年10月4日）和提交2254101，提交3d4548e（2019年10月3日）。^（由^{Junio C}^Hamano^合并^--^在^{commit d0ce4d9中}^{，2019年10月15日）}steadmon
^gitster

trace2：如果目标目录中的文件过多，则放弃新的跟踪

^{签字人：乔什·斯特德蒙（Josh Steadmon）}

trace2可以将文件写入目标目录。
如果使用量很大，此目录可能会充满文件，从而给跟踪处理系统带来困难。

该补丁添加了一个配置选项（trace2.maxFiles）来设置trace2将写入目标目录的最大文件数。

将maxFiles设置为正整数时，将启用以下行为：

什么时候trace2将文件写入目标目录，请首先检查是否应丢弃跟踪。在以下情况下，应放弃跟踪：

有一个哨兵文件，说明文件太多

或者，文件数超过trace2.maxFiles。
在后一种情况下，我们创建一个名为的哨兵文件，以git-trace2-discard加快以后的检查速度。

假设是一个单独的跟踪处理系统正在处理生成的跟踪。一旦处理并删除了哨兵文件，应该再次安全地生成新的跟踪文件。

的默认值trace2.maxFiles为零，这将禁用文件计数检查。

还可以使用新的环境变量覆盖配置GIT_TRACE2_MAX_FILES。

Git 2.24（2019年第四季度）教授trace2有关git push阶段的信息。

参见Josh Steadmon（）的 commit 25e4b80和commit 5fc3118（2019年10月2日）。^（由^{Junio C}^Hamano^合并^--^在^{3b9ec27号提交中}^{，2019年10月15日）}steadmon
^gitster

push：添加trace2检测

^{签字人：乔什·斯特德蒙（Josh Steadmon）}

在trace2区域添加transport.c，builtin/push.c以更好地跟踪在推送的各个阶段花费的时间：

清单参考

检查子模块

推送子模块

推裁判

在Git 2.25（2020年第一季度）中，其中一些Documentation/technical被移动到了头*.h文件中。

见提交6c51cb5，提交d95a77d，提交bbcfa30，提交f1ecbe0，提交4c4066d，提交7db0305，提交f3b9055，提交971b1f2，提交13aa9c8，提交c0be43f，提交19ef3dd，提交301d595，提交3a1b341，提交126c1cc，提交d27eb35，提交405c6b1，提交d3d7172，提交3f1480b，提交266f03e，提交13c4d7e（2019年11月17日）作者：Heba Waly（HebaWaly）。
^{（由Junio C gitsterHamano合并--在commit 26c816a中，2019年12月16日）}

trace2：将文档移至 trace2.h

^{签字人：Heba Waly}

将功能文档从Documentation/technical/api-trace2.txt移到trace2.h，这样开发人员可以更轻松地在代码旁边查找用法信息，而不是在另一个doc文件中查找它。

从文件中删除了功能文档部分，Documentation/technical/api-trace2.txt因为该文件包含的详细信息似乎更适合放在单独的doc文件中，并带有指向trace2.h中添加的doc文件的链接。此外，还删除了函数doc以避免产生冗余信息，这些信息很难与头文件中的文档保持同步。

（尽管重组对另一个命令有副作用，由Jeff King（）在cc4f2eb提交（2020年2月14日）中的Git 2.25.2（2020年3月）解释和修复。^（由^{Junio C Hamano}^合并^--^在^{提交中1235384}^{，2020年2月17日）}）peff
^gitster

使用Git 2.27（2020年第2季度）：增强了Trace2以允许记录环境变量。

参见Josh Steadmon（）的 commit 3d3adaa（2020年3月20日）。^（由^{Junio C}^Hamano^合并^--^在^{810dc64提交中}^{，2020年4月22日）}steadmon
^gitster

trace2：教Git记录环境变量

^{签名人：Josh Steadmon}
^{签名人：Jeff Hostetler}

通过trace2，Git已经可以记录有趣的配置参数（请参见trace2_cmd_list_config()功能）。但是，这可能会导致图片不完整，因为许多配置参数还允许通过环境变量进行覆盖。

为了获得更完整的日志，我们添加了一个新trace2_cmd_list_env_vars()功能和支持的实现，以预先存在的config param日志实现为模型。

在Git 2.27（2020年第二季度）中，教导显示进度表的代码路径也将start_progress()和stop_progress()调用用作region要跟踪的“ ”。

参见Emily Shaffer（）的 commit 98a1364（2020年5月12日）。^（由^{Junio C}^Hamano^合并^--^在^{d98abce提交中}^{，2020年5月14日）}nasamuffin
^gitster

trace2：记录进度时间和吞吐量

^{签名人：艾米莉·谢弗（Emily Shaffer）}

通过向进度库本身添加工具git fetch，我们可以学习大量的用户操作，这些操作似乎很慢，而不是只教一个操作（如“ ”）如何将吞吐量记录到跟踪中。

显示进度的操作可能运行缓慢，并且无论如何我们都希望监视性能。

通过显示对象计数和数据传输大小，我们应该能够进行一些派生的测量，以确保操作按我们期望的方式扩展。

和：

在Git 2.27（2020年第二季度）中，对我们最近的更改进行了最新修正，以允许将progress API用作可跟踪区域。

参见Derrick Stolee（）提交的3af029c（2020年5月15日）。^（由^{Junio C}^Hamano^合并^--^在^{commit 85d6e28中}^{，2020年5月20日）}derrickstolee
^gitster

progress：trace2_region_leave()仅在致电后致电_enter()

^{签字人：德里克·斯托利}

进度API的用户start_progress()有条件地调用，并且依赖于display_progress()和stop_progress()函数，而在start_progress()未调用时变为无操作。

由于我们增加了一个调用trace2_region_enter()到start_progress()，从进度API函数等TRACE2 API调用的调用必须确保这些TRACE2电话是跳过时start_progress()没有被调用的进展结构。

具体来说，不要在未调用时trace2_region_leave()从stop_progress()调用start_progress()，而这会调用匹配trace2_region_enter()。

— 冯
source

4

-v克隆时是否尝试添加冗长的（）运算符？

git clone -v git://git.kernel.org/pub/scm/.../linux-2.6 my2.6

— 詹姆斯·哈索尔
source

2

对于较旧的git版本（1.8及更低版本）

我找不到在较旧的git和ssh版本中启用SSH调试的合适方法。我使用查找环境变量ltrace -e getenv ...，但找不到可以正常使用的GIT_TRACE或SSH_DEBUG变量的任何组合。

相反，这是将ssh -v临时注入git-> ssh序列的方法：

$ echo '/usr/bin/ssh -v ${@}' >/tmp/ssh
$ chmod +x /tmp/ssh
$ PATH=/tmp:${PATH} git clone ...
$ rm -f /tmp/ssh

这是git版本1.8.3和ssh版本OpenSSH_5.3p1，OpenSSL 1.0.1e-fips的输出，2013年2月11日克隆github存储库：

$ (echo '/usr/bin/ssh -v ${@}' >/tmp/ssh; chmod +x /tmp/ssh; PATH=/tmp:${PATH} \
   GIT_TRACE=1 git clone https://github.com/qneill/cliff.git; \
   rm -f /tmp/ssh) 2>&1 | tee log
trace: built-in: git 'clone' 'https://github.com/qneill/cliff.git'
trace: run_command: 'git-remote-https' 'origin' 'https://github.com/qneill/cliff.git'
Cloning into 'cliff'...
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/q.neill/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com ...
...
Transferred: sent 4120, received 724232 bytes, in 0.2 seconds
Bytes per second: sent 21590.6, received 3795287.2
debug1: Exit status 0
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'

— 尼尔
source

如何调试git / git-shell相关问题？

调试

SSH协议

例子

`http.c`：实现`GIT_TRACE_CURL`环境变量

`trace2`：创建新的组合跟踪工具

`trace2`：写入目录目标

`trace2`：将环境变量重命名为GIT_TRACE2 *

common-main：延迟trace2初始化

`trace2`：如果目标目录中的文件过多，则放弃新的跟踪

`push`：添加trace2检测

`trace2`：将文档移至 `trace2.h`

`trace2`：教Git记录环境变量

`trace2`：记录进度时间和吞吐量

`progress`：`trace2_region_leave()`仅在致电后致电`_enter()`

对于较旧的git版本（1.8及更低版本）

如何调试git / git-shell相关问题？

调试

SSH协议

例子

http.c：实现GIT_TRACE_CURL环境变量

trace2：创建新的组合跟踪工具

trace2：写入目录目标

trace2：将环境变量重命名为GIT_TRACE2 *

common-main：延迟trace2初始化

trace2：如果目标目录中的文件过多，则放弃新的跟踪

push：添加trace2检测

trace2：将文档移至 trace2.h

trace2：教Git记录环境变量

trace2：记录进度时间和吞吐量

progress：trace2_region_leave()仅在致电后致电_enter()

对于较旧的git版本（1.8及更低版本）

`http.c`：实现`GIT_TRACE_CURL`环境变量

`trace2`：创建新的组合跟踪工具

`trace2`：写入目录目标

`trace2`：将环境变量重命名为GIT_TRACE2 *

`trace2`：如果目标目录中的文件过多，则放弃新的跟踪

`push`：添加trace2检测

`trace2`：将文档移至 `trace2.h`

`trace2`：教Git记录环境变量

`trace2`：记录进度时间和吞吐量

`progress`：`trace2_region_leave()`仅在致电后致电`_enter()`