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

问题描述

| 如何获得有关git / git-shell的调试信息？ 我有一个问题，0可以毫无问题地克隆存储库，而1只能克隆一个空的存储库。我设定了

GIT_TRACE=1

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

解决方法

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

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master

    ,        调试 Git嵌入了相当完整的跟踪集，可用于调试git问题。 要打开它们，可以定义以下变量：

GIT_TRACE

一般迹线，

GIT_TRACE_PACK_ACCESS

，用于跟踪包文件访问，

GIT_TRACE_PACKET

用于网络操作的数据包级跟踪，

GIT_TRACE_PERFORMANCE

用于记录性能数据，

GIT_TRACE_SETUP

，了解有关发现与其交互的存储库和环境的信息， “ 9”用于调试递归合并策略（值：0-5），

GIT_CURL_VERBOSE

用于记录所有curl消息（相当于

curl -v

），

GIT_TRACE_SHALLOW

调试浅层存储库的获取/克隆。 可能的值包括：

true

，

1

或

2

写入stderr， 以ѭ16开头的绝对路径，用于将输出跟踪到指定文件。 有关更多详细信息，请参见：Git内部-环境变量 SSH协议 对于SSH问题，请尝试以下命令：

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

或使用“ 18”来验证您的凭据，例如

ssh -vvvT [e-mail]

或通过HTTPS端口：

ssh -vvvT -p 443 [e-mail]

注意：减少number21的数量以降低详细程度。 例子

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

    ,        试试这个：

GIT_TRACE=1 git pull origin master

    ,        如果通过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 \'。     ,        Git 2.9.x / 2.10（2016年第三季度）增加了另一个调试选项：

GIT_TRACE_CURL

。 参见Elia Pinto（

devzero2000

）的提交73e57aa，提交74c682d（2016年5月23日）。 助手：托尔斯滕·博格斯豪森（

tboegi

），拉姆齐·琼斯（Ramsay Jones），朱尼奥·C·哈马诺（Jun28ѭ），埃里克·阳光（

sunshineco

）和杰夫·金（

peff

）。 （由Junio C Hamano合并-

gitster

-在2f84df2次提交中，2016年7月6日）   

http.c

：实现the25ѭ环境变量      实现

GIT_TRACE_CURL

环境变量，以允许更大程度地了解

GIT_CURL_VERBOSE

，尤其是完整的传输头和交换的所有数据有效载荷。   如果特定情况可能需要更彻底的调试分析，这可能会很有用。 该文档将说明：

GIT_TRACE_CURL

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

curl --trace-ascii

。      此选项将覆盖设置“ 10”环境变量。 您可以在此答案中以及Git 2.11（Q4 2016）测试中看到使用的新选项： 参见Elia Pinto（

devzero2000

）的提交14e2411，提交81590bf，提交4527aa1，提交4eee6c6（2016年9月7日）。 （由Junio C Hamano合并-

gitster

-在commit 930b67e中，2016年9月12日）   请改用新的

GIT_TRACE_CURL

环境变量   已淘汰的ѭ10中的。

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

    ,        克隆时是否尝试添加冗长的（

-v

）运算符？

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

    ,        对于较旧的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\'

    ,Git 2.22（Q2 2019）在Jeff Hostetler提交的ee4512e中引入了

trace2

：   

trace2

：创建新的组合跟踪工具      为git创建一个新的统一跟踪工具。   最终目的是用统一的

git_trace2*

例程替换当前的

trace_printf*

和

trace_performance*

例程。      除了通常的printf样式的API之外，

trace2

还提供了更高级别的   具有固定字段的事件动词，允许写入结构化数据。   这使得外部工具的后处理和分析更加容易。      Trace2定义了3个输出目标。   使用环境变量\“

GIT_TR2

\”，\“

GIT_TR2_PERF

\”和\“

GIT_TR2_EVENT

\”进行设置。   这些可以设置为\“ 1 \”或绝对路径名（就像当前的

GIT_TRACE

一样）。 注意：关于环境变量名称，请始终使用

GIT_TRACExxx

，而不是

GIT_TRxxx

。 因此实际上是

GIT_TRACE2

，

GIT_TRACE2_PERF

或

GIT_TRACE2_EVENT

。 请参阅下面稍后提到的Git 2.22重命名。 以下是使用旧的环境变量名称对该新跟踪功能进行的初步工作：      

GIT_TR2

旨在替代

GIT_TRACE

和logs命令   摘要数据。   

GIT_TR2_PERF

旨在替代

GIT_TRACE_PERFORMANCE

。   它将输出扩展为命令进程，线程，   回购，绝对和相对经过时间。它报告事件   子进程启动/停止，线程启动/停止和每线程功能   嵌套。   

GIT_TR2_EVENT

是一种新的结构格式。它将事件数据写为   系列JSON记录。         调用trace2函数将记录到启用的3个输出目标中的任何一个，而无需调用不同的“ 51”或“ 52”例程。 参见Josh Steadmon（

steadmon

）的commit a4d3a28（2019年3月21日）。 （由Junio C Hamano合并-

gitster

-第1b40314次提交，2019年5月8日）   

trace2

：写入目录目标      当trace2环境变量的值是引用现有目录的绝对路径时，请将输出写入给定目录下的文件（每个进程一个）。   文件将根据trace2 SID的最终组成部分命名，然后加上一个计数器以避免潜在的冲突。      这使得为​​每次git调用收集跟踪更加方便   通过无条件地将相关的ѭ49envvar设置为常数   目录名称。 另请参阅Jeff Hostetler（

jeffhostetler

）（提交） ）。 （由Junio C Hamano合并-

gitster

-提交5b2d1c0,2019年5月13日） 现在，新文档包括仅从系统和全局配置文件读取的配置设置（这意味着不考虑存储库本地和工作树配置文件以及and77ѭ命令行参数）。 例：

$ 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（

carenas

）提交6114a40（2019年6月26日）。 参见ÆvarArnfjörðBjarmason（

avar

）的commit 3efa1c6（2019年6月12日）。 （由Junio C Hamano合并-

gitster

-在commit e9eaaa4中，2019年7月9日） 紧随Git 2.22中的工作：SZEDERGábor（

szeder

）提交4e0d3aa，commit e4b75d6（2019年5月19日）。 （由Junio C Hamano合并-

gitster

-提交463dca6,2019年5月30日）   

trace2

：将环境变量重命名为GIT_TRACE2 *      对于应该由用户设置的环境变量，

GIT_TR2*

env vars太不清楚，不一致和丑陋。      大部分已建立的

GIT_*

环境变量不使用   缩写，如果是少数几个缩写（

GIT_DIR

，

GIT_COMMON_DIR

，

GIT_DIFF_OPTS

），则缩写（

DIR

和

OPTS

）代表的含义很明显。   但是ѭ96代表什么？追踪，传统，拖车，交易，转移，转换，过渡，翻译，移植，运输，遍历，树，   触发，截断，信任还是...？！      就像其名称中带有“ 2”的后缀一样，trace2工具是   应该最终取代了Git的原始跟踪工具。   合理预期相应的环境变量   跟随，并在原始

GIT_TRACE

变量之后   叫ѭ61没有这样的东西是\'

GIT_TR

\'。      非常明智的是，所有特定于trace2的配置变量都位于   \'

trace2

\'部分，不在\'

tr2

\'中。      太太，我们省略了最后三个，一无所获   这些环境变量的名称中的\“ trace \”字符。      因此，让我们将所有

GIT_TR2*

环境变量重命名为

GIT_TRACE2*

，   在他们进入稳定版本之前。 Git 2.24（Q3 2019）改进了Git存储库的初始化。 参见Jeff King（

peff

）的提交22932d9，提交5732f2b和提交58ebccb（2019年8月6日）。 （由Junio C Hamano合并-

gitster

-在commit b4a1eec中，2019年9月9日）   common-main：延迟trace2初始化      我们在通用main（）函数中初始化

trace2

系统，以便   所有程序（甚至不是内置程序）都将启用跟踪。      但是，

trace2

创业公司相对来说是重量级的，因为我们必须实际阅读   磁盘上的配置来决定是否跟踪。   这可能会导致与其他公用主初始化的意外交互。例如，在调用

initialize_the_repository()

之前，我们将进入配置代码，and109ѭ永不为NULL的通常不变式将不成立。      让我们将

trace2

初始化在通用主电源中进一步向下推，   在执行execute111ѭ之前。 Git 2.24（Q4 2019）还确保现在从

trace2

子系统输出的格式更加简洁。 请参阅Jeff Hostetler（

jeffhostetler

）的提交742ed63，提交e344305，提交c2b890a（2019年8月9日），提交ad43e37，提交04f10d3，提交da4589c（2019年8月8日）和提交371df1b（2019年7月31日）。 （由Junio C Hamano合并-

gitster

-第93fc876次提交，2019年9月30日） 而且，仍然是Git 2.24 请参见Josh Steadmon（

steadmon

）的提交87db61a，提交83e57b0（2019年10月4日）和提交2254101，提交3d4548e（2019年10月3日）。 （由Junio C Hamano合并-

gitster

-提交d0ce4d9,2019年10月15日）   

trace2

：如果目标目录中的文件过多，则丢弃新的跟踪      签字人：乔什·斯特德蒙（Josh Steadmon）      ѭ49可以将文件写入目标目录。   如果使用量很大，此目录可能会充满文件，从而给跟踪处理系统带来困难。      此修补程序添加了一个配置选项（

trace2.maxFiles

）来设置

trace2

将写入目标目录的最大文件数。      将ѭ121设置为正整数时，将启用以下行为：         当“ 49”将文件写入目标目录时，首先检查是否应放弃跟踪。在以下情况下，应放弃跟踪：         有一个哨兵文件，说明文件太多   或者，文件数超过ѭ119。   在后一种情况下，我们创建一个名为

git-trace2-discard

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

trace2.maxFiles

的默认值为零，这将禁用文件计数检查。      也可以使用新的环境变量覆盖该配置：

GIT_TRACE2_MAX_FILES

。 Git 2.24（Q4 2019）教授trace2约

git push

个阶段。 参见Josh Steadmon（

steadmon

）的commit 25e4b80，commit 5fc3118（2019年10月2日）。 （由Junio C Hamano合并-

gitster

-在3b9ec27号提交中，2019年10月15日）   

push

：添加trace2仪器      签字人：乔什·斯特德蒙（Josh Steadmon）      在

transport.c

和

builtin/push.c

中添加trace2区域，以更好地跟踪在推送的各个阶段花费的时间：         清单参考   检查子模块   推送子模块   推裁判    在Git 2.25（2020年第一季度）中，某些ѭ133moved已移至标头

*.h

文件中。 请参见提交6c51cb5，提交d95a77d，提交bbcfa30，提交f1ecbe0，提交4c4066d，提交7db0305，提交f3b9055，提交971b1f2，提交13aa9c8，提交c0be43f，提交19ef3dd，提交301d595，提交3a1b341，提交6c12727，提交126c12727 d3d7172，提交3f1480b，提交266f03e，提交13c4d7e（2019年11月17日），作者是Heba Waly（

HebaWaly

）。 （由Junio C Hamano合并-

gitster

-在commit 26c816a中，2019年12月16日）   

trace2

：将文档移至

trace2.h

     签字人：Heba Waly      将功能文档从

Documentation/technical/api-trace2.txt

移至

trace2.h

，因为开发人员可以更轻松地在代码旁边查找用法信息，而不必在另一个doc文件中查找它。      ѭ139中仅删除了功能文档部分，因为该文件包含的详细信息似乎更适合放在单独的doc文件中，并带有指向trace2.h中的doc文件的链接。此外，函数doc也被删除，以避免产生多余的信息，这将很难与头文件中的文档保持同步。