And*_*dor 130 git debugging trace
我如何获得有关git/git-shell的一些调试信息？
我有一个问题,user1可以克隆存储库没有问题,而user2只能克隆一个空的.我设定了GIT_TRACE=1,但没有任何有用的东西被告知.
最后,经过长时间的反复试验,结果证明这是文件的权限问题.适当的错误消息可能会使此问题短路.
WTK*_*WTK 186
对于更详细的输出使用如下:
GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master
ken*_*orb 69
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写信给标准错误,/跟踪输出到指定文件开始的绝对路径.有关更多详细信息,请参阅:Git内部 - 环境变量
对于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
...
Bas*_*usa 36
如果是通过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'.
Von*_*onC 18
Git 2.9.x/2.10(2016年第3季度)增加了另一个调试选项:GIT_TRACE_CURL.
请参阅Elia Pinto()提交73e57aa,提交74c682d(2016年5月23日).
帮助:TorstenBögershausen(),Ramsay Jones,Junio C Hamano(),Eric Sunshine()和Jeff King().(由Junio C Hamano合并- -在提交2f84df2,2016年7月6日)devzero2000tboegigitstersunshinecopeff
gitster
http.c:实现GIT_TRACE_CURL环境变量实现
GIT_TRACE_CURL环境变量以允许更大程度的细节GIT_CURL_VERBOSE,特别是完整的传输头和交换的所有数据有效负载.
如果特定情况需要更彻底的调试分析,这可能会有用.
文档将说明:
GIT_TRACE_CURL
启用git传输协议的所有传入和传出数据(包括描述性信息)的卷曲完整跟踪转储.
这类似于curl --trace-ascii在命令行上执行.此选项会覆盖设置
GIT_CURL_VERBOSE环境变量.
您可以在此答案中看到新选项,但也可以在Git 2.11(2016年第4季度)测试中看到:
请参阅提交14e2411,提交81590bf,提交4527aa1,提交4eee6c6(2016年9月7日)作者:Elia Pinto(devzero2000).
(由Junio C gitsterHamano合并- -在提交930b67e,2016年9月12日)
使用新的
GIT_TRACE_CURL环境变量而不是弃用的GIT_CURL_VERBOSE.
GIT_TRACE_CURL=true git clone --quiet $HTTPD_URL/smart/repo.git
Von*_*onC 11
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”或绝对路径名（就像当前的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.
它使用命令进程、线程、repo、绝对和相对经过时间的列扩展输出。
它报告子进程启动/停止、线程启动/停止和每线程函数嵌套的事件。
GIT_TR2_EVENT是一种新的结构化格式。它将事件数据作为一系列 JSON 记录写入。对 trace2 函数的调用记录到启用的 3 个输出目标中的任何一个，而无需调用不同的
trace_printf*或trace_performance*例程。
请参阅Josh Steadmon ( )提交的 a4d3a28（2019 年 3 月 21 日）。（由Junio C Hamano合并-- --在commit 1b40314，2019 年 5 月 8 日）steadmon
gitster
trace2: 写入目录目标
当 trace2 环境变量的值是引用现有目录的绝对路径时，将输出写入给定目录下的文件（每个进程一个）。
文件将根据 trace2 SID 的最终组成部分命名，后跟一个计数器以避免潜在的冲突。通过无条件地将相关的
trace2envvar设置为一个常量目录名称，这使得为每个 git 调用收集跟踪变得更加方便。
参见提交f672dee（2019年4月29日），以及提交81567ca，提交08881b9，提交bad229a，提交26c6f25，提交bce9db6，提交800a7f9，提交a7bc01e，提交39f4317，提交a089724，提交1703751（2019年4月15日）由杰夫霍斯泰特勒（jeffhostetler） .
（由Junio C gitsterHamano合并-- --在提交 5b2d1c0 中，2019 年 5 月 13 日）
在新文档现在包括它只能从系统和全局配置文件中读取配置设置（意库本地和worktree配置文件和-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（2019 年第三季度）中所述，要使用的环境变量是GIT_TRACE2.
请参阅Carlo Marcelo Arenas Belón ( ) 的commit 6114a40（2019 年 6 月 26 日）。
请参阅Ævar Arnfjörð Bjarmason ( ) 的提交 3efa1c6（2019 年 6 月 12 日）。（由Junio C Hamano合并-- --在提交 e9eaaa4，2019 年 7 月 9 日）carenasavar
gitster
这是在 Git 2.22 中完成的工作：提交 4e0d3aa，提交 e4b75d6（2019 年 5 月 19 日）由SZEDER Gábor ( szeder)。
（由Junio C gitsterHamano合并-- --在提交 463dca6 中，2019 年 5 月 30 日）
trace2: 将环境变量重命名为 GIT_TRACE2*
对于应该由用户设置的环境变量，环境变量
GIT_TR2*太不清楚、不一致和丑陋。大多数已建立的
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（2019 年第三季度）改进了 Git 存储库初始化。
请参阅Jeff King ( ) 的commit 22932d9、commit 5732f2b、commit 58ebccb（2019 年 8 月 6 日）。（由Junio C Hamano合并-- --在提交 b4a1eec，2019 年 9 月 9 日）peff
gitster
common-main: 延迟 trace2 初始化
我们
trace2在通用的 main() 函数中初始化系统，以便所有程序（即使不是内置程序）都可以启用跟踪。但是
trace2启动是比较重要的，因为我们必须实际读取磁盘配置来决定是否进行跟踪。
这可能会导致与其他公共主初始化的意外交互。例如，我们将在调用之前在配置代码中结束initialize_the_repository()，并且the_repository从不为 NULL的通常不变量将不成立。让我们将
trace2common-main 中的初始化进一步推到我们执行之前cmd_main()。
Git 2.24（2019 年第四季度）还确保trace2现在子系统的输出格式更漂亮。
见提交742ed63，提交e344305，提交c2b890a（2019年8月9日），提交ad43e37，提交04f10d3，提交da4589c（2019年8月8日），并提交371df1b（2019年7月31日），由杰夫·霍斯泰特勒（jeffhostetler）。
（由Junio C gitsterHamano合并-- --在提交 93fc876 中，2019 年 9 月 30 日）
而且，仍然是 Git 2.24
请参阅Josh Steadmon ( ) 的commit 87db61a、commit 83e57b0（2019 年 10 月 4 日）和commit 2254101、commit 3d4548e（2019 年 10 月 3 日）。（由Junio C Hamano合并-- --在d0ce4d9 提交中，2019 年 10 月 15 日）steadmon
gitster
trace2: 如果目标目录有太多文件，则丢弃新的痕迹签字人：乔什·斯特德蒙
trace2可以将文件写入目标目录。
大量使用时，此目录可能会填满文件，从而给跟踪处理系统带来困难。此补丁添加了一个配置选项 (
trace2.maxFiles) 来设置trace2将写入目标目录的最大文件数。当
maxFiles设置为正整数时启用以下行为：
- 何时
trace2将文件写入目标目录，首先检查是否应丢弃跟踪。
如果出现以下情况，应丢弃痕迹：
- 有一个哨兵文件声明文件太多
- 或者，文件数量超过
trace2.maxFiles.
在后一种情况下，我们创建一个名为的哨兵文件以git-trace2-discard加快未来的检查。假设是一个单独的跟踪处理系统正在处理生成的跟踪；一旦它处理并删除了哨兵文件，再次生成新的跟踪文件应该是安全的。
的默认值
trace2.maxFiles为零，这将禁用文件计数检查。也可以使用新的环境变量覆盖配置：
GIT_TRACE2_MAX_FILES.
Git 2.24（2019 年第 4 季度）教 trace2 关于git push阶段。
请参阅Josh Steadmon ( ) 的commit 25e4b80和commit 5fc3118（2019 年 10 月 2 日）。（由Junio C Hamano合并-- --在3b9ec27 提交中，2019 年 10 月 15 日）steadmon
gitster
push: 添加 trace2 检测签字人：乔什·斯特德蒙
添加 trace2 区域
transport.c并builtin/push.c更好地跟踪在推送的各个阶段花费的时间：
- 列表参考
- 检查子模块
- 推送子模块
- 推送参考
在 Git 2.25（2020 年第一季度）中，其中一些Documentation/technical被移到头*.h文件中。
您是否尝试过-v在克隆时添加详细的 ( ) 运算符？
git clone -v git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
| 归档时间： |
|
| 查看次数： |
94574 次 |
| 最近记录： |