您是否尝试在克隆时添加详细(-v)操作符?

Git克隆-v Git://git.kernel.org/pub/scm/.../linux-2.6 my2.6

试试这个:

GIT_TRACE=1 git pull origin master

要获得更详细的输出，请使用以下方法:

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git拉源主

如果是SSH，你可以使用以下命令:

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

# 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年Q3)增加了另一个调试选项:GIT_TRACE_CURL。

参见Elia Pinto (devzero2000)的commit 73e57aa, commit 74c682d(2016年5月23日)。 帮助:Torsten Bögershausen (tboegi)， Ramsay Jones ramsay@ramsayjones.plus.com, Junio C Hamano (gitster)， Eric Sunshine (sunshineco)，和Jeff King (peff)。 (由Junio C Hamano—gitster—在提交2f84df2中合并，2016年7月6日)

c:实现GIT_TRACE_CURL环境变量

实现GIT_TRACE_CURL环境变量，以允许更详细地了解GIT_CURL_VERBOSE，特别是完整的传输报头和交换的所有数据有效负载。 如果某个特定的情况需要更彻底的调试分析，那么它可能会很有用。

该文件将说明:

GIT_TRACE_CURL 启用所有传入和传出数据的curl完整跟踪转储，包括git传输协议的描述性信息。 这类似于在命令行上执行curl——trace-ascii。 该选项将覆盖设置GIT_CURL_VERBOSE环境变量。

---

你可以在这个答案中看到这个新选项，在Git 2.11(2016年Q4)测试中也有使用:

参见Elia Pinto (devzero2000)的commit 14e2411, commit 81590bf, commit 4527aa1, commit 4eee6c6(2016年9月07日)。 (由Junio C Hamano—gitster—在commit 930b67e中合并，2016年9月12日)

请使用新的GIT_TRACE_CURL环境变量 已弃用的GIT_CURL_VERBOSE。

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

---

请注意，并非所有命令都必须发出跟踪。 例如:你需要Git 2.32 (Q2 2021)才能让reflog失效机制发出跟踪事件。

参见hanwen Nienhuys提交的34c3199(2021年4月23日)。 (由Junio C Hamano—gitster—在commit a850356中合并，2021年5月7日)

参考/调试:跟踪到reflog到期 签署人:Han-Wen Nienhuys

---

使用Git 2.39 (Q4 2022)，在GIT_CURL_VERBOSE和其他文件中编校cURL的h2h3模块的头文件。

参见Glen Choo (chooglen)提交的b637a41(2022年11月11日)。 参见Jeff King (peff)提交73c49a4(2022年11月11日)。 (由Junio C Hamano—gitster—在commit 6adf170中合并，2022年11月23日)

Http:在info中编辑curl h2h3头文件 资助人:杰夫·金 署名:Glen Choo 署名:泰勒·布劳

With GIT_TRACE_CURL=1 or GIT_CURL_VERBOSE=1, sensitive headers like "Authorization" and "Cookie" get redacted. However, since curl/curl commit f8c3724, curl's h2h3 module (invoked when using HTTP/2) also prints headers in its "info", which don't get redacted. For example, echo 'github.com TRUE / FALSE 1698960413304 o foo=bar' >cookiefile && GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 git \ -c 'http.cookiefile=cookiefile' \ -c 'http.version=' \ ls-remote https://github.com/git/git refs/heads/main 2>output && grep 'cookie' output produces output like: 23:04:16.920495 http.c:678 == Info: h2h3 [cookie: o=foo=bar] 23:04:16.920562 http.c:637 => Send header: cookie: o=<redacted> Teach http.c to check for h2h3 headers in info and redact them using the existing header redaction logic. This fixes the broken redaction logic that we noted in the previous commit, so mark the redaction tests as passing under HTTP2.

调试

Git有一个相当完整的嵌入式跟踪集，您可以使用它来调试Git问题。

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

GIT_TRACE for general traces, GIT_TRACE_PACK_ACCESS for tracing of packfile access, GIT_TRACE_PACKET for packet-level tracing for network operations, GIT_TRACE_PERFORMANCE for logging the performance data, GIT_TRACE_SETUP for information about discovering the repository and environment it’s interacting with, GIT_MERGE_VERBOSITY for debugging recursive merge strategy (values: 0-5), GIT_CURL_VERBOSE for logging all curl messages (equivalent to curl -v), GIT_TRACE_SHALLOW for debugging fetching/cloning of shallow repositories.

可能的值包括:

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

Git 2.22(2019年第二季度)引入了提交ee4512e的trace2:

Trace2:创建新的组合跟踪工具

Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE).

注意:对于环境变量名称，总是使用GIT_TRACExxx，而不是GIT_TRxxx。 实际上是GIT_TRACE2, GIT_TRACE2_PERF或GIT_TRACE2_EVENT。 请参阅后面提到的Git 2.22重命名。

下面是这个新的跟踪特性的初始工作，使用旧的环境变量名:

GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines.

参见Josh Steadmon (Steadmon)的commit a4d3a28(2019年3月21日)。 (由Junio C Hamano—gitster—在提交1b40314中合并，2019年5月8日)

Trace2:写入目录目标

当trace2环境变量的值是指向现有目录的绝对路径时，将输出写入给定目录下的文件(每个进程一个)。 文件将根据trace2 SID的最后一个组件命名，后面跟着一个计数器以避免潜在的冲突。 这使得为每个git调用收集跟踪更加方便 通过无条件地将相关的trace2 envvar设置为常量 目录名称。

---

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

新文档现在包含了仅从系统和全局配置文件读取的配置设置(这意味着存储库本地和工作树配置文件以及-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。

参见卡洛·马塞洛·阿里纳斯提交的6114a40(2019年6月26日)Belón (carenas)。 参见提交3efa1c6 (12 Jun 2019) Ævar Arnfjörð Bjarmason (avar)。 (由Junio C Hamano - gitster -在commit e9eaaa4中合并，2019年7月9日)

这遵循了Git 2.22中所做的工作:通过SZEDER Gábor (SZEDER)提交4e0d3aa，提交e4b75d6(2019年5月19日)。 (由Junio C Hamano—gitster—在commit 463dca6中合并，2019年5月30日)

trace2:重命名环境变量为GIT_TRACE2*

For an environment variable that is supposed to be set by users, the GIT_TR2* env vars are just too unclear, inconsistent, and ugly. Most of the established GIT_* environment variables don't use abbreviations, and in case of the few that do (GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) it's quite obvious what the abbreviations (DIR and OPTS) stand for. But what does TR stand for? Track, traditional, trailer, transaction, transfer, transformation, transition, translation, transplant, transport, traversal, tree, trigger, truncate, trust, or ...?! The trace2 facility, as the '2' suffix in its name suggests, is supposed to eventually supercede Git's original trace facility. It's reasonable to expect that the corresponding environment variables follow suit, and after the original GIT_TRACE variables they are called GIT_TRACE2; there is no such thing is 'GIT_TR'. All trace2-specific config variables are, very sensibly, in the 'trace2' section, not in 'tr2'. OTOH, we don't gain anything at all by omitting the last three characters of "trace" from the names of these environment variables. So let's rename all GIT_TR2* environment variables to GIT_TRACE2*, before they make their way into a stable release.

---

Git 2.24(2019年Q3)改进了Git存储库初始化。

参见Jeff King (peff)的commit 22932d9, commit 5732f2b, commit 58ebccb(2019年8月06日)。 (由Junio C Hamano—gitster—在commit b4a1eec中合并，2019年9月9日)

Common-main:延迟trace2初始化

We initialize the trace2 system in the common main() function so that all programs (even ones that aren't builtins) will enable tracing. But trace2 startup is relatively heavy-weight, as we have to actually read on-disk config to decide whether to trace. This can cause unexpected interactions with other common-main initialization. For instance, we'll end up in the config code before calling initialize_the_repository(), and the usual invariant that the_repository is never NULL will not hold. Let's push the trace2 initialization further down in common-main, to just before we execute cmd_main().

---

Git 2.24(2019年Q4)还确保来自trace2子系统的输出现在格式化得更漂亮。

参见Jeff Hostetler (jeffhostetler)的commit 742ed63、commit e344305、commit c2b890a(2019年8月09日)、commit ad43e37、commit 04f10d3、commit da4589c(2019年8月08日)和commit 371df1b(2019年7月31日)。 (由Junio C Hamano—gitster—在commit 93fc876中合并，2019年9月30日)

并且，仍然是Git 2.24

参见Josh Steadmon (Steadmon)的commit 87db61a, commit 83e57b0(2019年10月04日)和commit 2254101, commit 3d4548e(2019年10月03日)。 (由Junio C Hamano—gitster—在commit d0ce4d9中合并，2019年10月15日)

Trace2:如果目标目录有太多文件，则丢弃新的跟踪 署名:Josh Steadmon

trace2 can write files into a target directory. With heavy usage, this directory can fill up with files, causing difficulty for trace-processing systems. This patch adds a config option (trace2.maxFiles) to set a maximum number of files that trace2 will write to a target directory. The following behavior is enabled when the maxFiles is set to a positive integer: When trace2 would write a file to a target directory, first check whether or not the traces should be discarded. Traces should be discarded if: there is a sentinel file declaring that there are too many files OR, the number of files exceeds trace2.maxFiles. In the latter case, we create a sentinel file named git-trace2-discard to speed up future checks. The assumption is that a separate trace-processing system is dealing with the generated traces; once it processes and removes the sentinel file, it should be safe to generate new trace files again. The default value for trace2.maxFiles is zero, which disables the file count check. The config can also be overridden with a new environment variable: GIT_TRACE2_MAX_FILES.

---

Git 2.24(2019年Q4)教trace2关于Git推送阶段。

参见Josh Steadmon (Steadmon)的commit 25e4b80, commit 5fc3118(2019年10月02日)。 (由Junio C Hamano—gitster—在commit 3b9ec27中合并，2019年10月15日)

Push:添加trace2 instrumentation 署名:Josh Steadmon

在transport.c和内置/push.c中添加trace2区域，以更好地跟踪在不同推送阶段所花费的时间: 列出参考文献 检查子 将子 把参考文献

---

在Git 2.25 (Q1 2020)中，一些文档/技术文件被移动到头文件*.h中。

参见HebaWaly (HebaWaly)的commit 6c51cb5、commit d95a77d、commit bbcfa30、commit f1ecbe0、commit 4c4066d、commit 7db0305、commit f3b9055、commit 971b1f2、commit 13aa9c8、commit c0be43f、commit 19ef3dd、commit 301d595、commit 3a1b341、commit 126c1cc、commit d27eb35、commit 405c6b1、commit d3d7172、commit 3f1480b、commit 266f03e、commit 13c4d7e(2019年11月17日)。 (由Junio C Hamano - gitster -在commit 26c816a中合并，2019年12月16日)

Trace2:移动doc到Trace2 .h 署名:Heba Waly

Move the functions documentation from Documentation/technical/api-trace2.txt to trace2.h as it's easier for the developers to find the usage information beside the code instead of looking for it in another doc file. Only the functions documentation section is removed from Documentation/technical/api-trace2.txt as the file is full of details that seemed more appropriate to be in a separate doc file as it is, with a link to the doc file added in the trace2.h. Also the functions doc is removed to avoid having redundandt info which will be hard to keep syncronized with the documentation in the header file.

(尽管重组对另一个命令有副作用，Jeff King在commit cc4f2eb(2020年2月14日)中解释并修复了Git 2.25.2(2020年3月)。 (由Junio C Hamano - gitster -在commit 1235384,2020年2月17日合并))

---

Git 2.27 (Q2 2020): Trace2增强，允许记录环境变量。

参见Josh Steadmon (Steadmon)提交3d3adaa (20 Mar 2020)。 (由Junio C Hamano—gitster—在commit 810dc64中合并，2020年4月22日)

trace2:教Git记录环境变量 署名:Josh Steadmon 致谢人:Jeff Hostetler

通过trace2, Git已经可以记录有趣的配置参数(参见trace2_cmd_list_config()函数)。然而，这可能会导致画面不完整，因为许多配置参数也允许通过环境变量进行覆盖。 为了允许更完整的日志，我们添加了一个新的trace2_cmd_list_env_vars()函数和支持的实现，它模仿了预先存在的配置参数日志记录实现。

---

在Git 2.27 (Q2 2020)中，教会显示进度计的代码路径也使用start_progress()和stop_progress()调用作为要跟踪的“区域”。

参见艾米丽·谢弗(nasamuffin)提交的98a1364(2020年5月12日)。 (由Junio C Hamano - gitster -在commit d98abce中合并，2020年5月14日)

Trace2:日志进度时间和吞吐量 署名:Emily Shaffer

Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect.

And:

在Git 2.27(2020年第二季度)中，最后一刻修复了我们最近的更改，允许使用进度API作为可跟踪区域。

参见Derrick Stolee (derrickstolee)提交的commit 3af029c(2020年5月15日)。 (由Junio C Hamano—gitster—在提交85d6e28中合并，2020年5月20日)

进度:只在调用_enter()后调用trace2_region_leave() 署名:Derrick Stolee

A user of progress API calls start_progress() conditionally and depends on the display_progress() and stop_progress() functions to become no-op when start_progress() hasn't been called. As we added a call to trace2_region_enter() to start_progress(), the calls to other trace2 API calls from the progress API functions must make sure that these trace2 calls are skipped when start_progress() hasn't been called on the progress struct. Specifically, do not call trace2_region_leave() from stop_progress() when we haven't called start_progress(), which would have called the matching trace2_region_enter().

---

最后一部分在Git 2.29(2020年第四季度)中更加健壮:

参见commit ac900fd (10 Aug 2020) by Martin Ågren (none)。 (由Junio C Hamano—gitster—在commit e6ec620中合并，2020年8月17日)

progress:在检查NULL之前不要解引用 署名:Martin Ågren

在stop_progress()中，在解引用p_progress之前，我们会仔细检查p_progress是否为非null，但在调用finish_if_sparse(*p_progress)时，我们已经解引用了它。 而且，为了它的价值，我们将继续在stop_progress_msg()中再次盲目地解除对它的引用。

---

在Git 2.29(2020年Q4)中，有更多的痕迹，这一次是在Git开发环境中。

参见hanwen Nienhuys (hanwen) commit 4441f42 (09 Sep 2020)。 (由Junio C Hamano—gitster—在commit c9a04f0中合并，2020年9月22日)

refs:增加GIT_TRACE_REFS调试机制 签署人:Han-Wen Nienhuys

When set in the environment, GIT_TRACE_REFS makes git print operations and results as they flow through the ref storage backend. This helps debug discrepancies between different ref backends. Example: $ GIT_TRACE_REFS="1" ./git branch 15:42:09.769631 refs/debug.c:26 ref_store for .git 15:42:09.769681 refs/debug.c:249 read_raw_ref: HEAD: 0000000000000000000000000000000000000000 (=> refs/heads/ref-debug) type 1: 0 15:42:09.769695 refs/debug.c:249 read_raw_ref: refs/heads/ref-debug: 3a238e539bcdfe3f9eb5010fd218640c1b499f7a (=> refs/heads/ref-debug) type 0: 0 15:42:09.770282 refs/debug.c:233 ref_iterator_begin: refs/heads/ (0x1) 15:42:09.770290 refs/debug.c:189 iterator_advance: refs/heads/b4 (0) 15:42:09.770295 refs/debug.c:189 iterator_advance: refs/heads/branch3 (0)

Git现在在它的手册页中包括:

GIT_TRACE_REFS 为ref数据库上的操作启用跟踪消息。 有关可用的跟踪输出选项，请参阅GIT_TRACE。

---

在Git 2.30 (Q1 2021)中，像die()和error()一样，调用warning()也会触发trace2事件。

参见Jonathan Tan (jhowtan)提交0ee10fd(2020年11月23日)。 (由Junio C Hamano—gitster—在commit 2aeafbc中合并，2020年12月8日)

用法:在警告()时添加trace2条目 署名:乔纳森·谭

Emit a trace2 error event whenever warning() is called, just like when die(), error(), or usage() is called. This helps debugging issues that would trigger warnings but not errors. In particular, this might have helped debugging an issue I encountered with commit graphs at $DAYJOB. There is a tradeoff between including potentially relevant messages and cluttering up the trace output produced. I think that warning() messages should be included in traces, because by its nature, Git is used over multiple invocations of the Git tool, and a failure (currently traced) in a Git invocation might be caused by an unexpected interaction in a previous Git invocation that only has a warning (currently untraced) as a symptom - as is the case in here.

---

使用Git 2.35 (Q1 2022)，出口被正确跟踪:

参见Ævar Arnfjörð Bjarmason (avar)提交368b584(2021年12月07日)。 (由Junio C Hamano—gitster—在提交67b7017中合并，2021年12月22日)

Common-main.c:调用exit()，不返回 署名:Ævar Arnfjörð Bjarmason

Change the main() function to call "exit()" instead of ending with a "return" statement. The "exit()" function is our own wrapper that calls trace2_cmd_exit_fl() for us, from git-compat-util.h: #define exit(code) exit(trace2_cmd_exit_fl(__FILE__, __LINE__, (code))) That "exit()" wrapper has been in use ever since ee4512e ("trace2: create new combined trace facility", 2019-02-22, Git v2.22.0-rc0 -- merge listed in batch #2). There is already code immediately downstream of our "main()" which has a hard reliance on that, e.g. the various "exit()" calls downstream of "cmd_main()" in "git.c".

---

在Git 2.36 (Q2 2022)中，进度API在跟踪方面更加健壮。

参见commit b3118a5, commit 74900a6, commit accf1eb, commit 1ccad6a, commit a02014b, commit bbfb1c2, commit 791afae, commit 587c3d0, commit 8266e0c (03 Feb 2022) by Ævar Arnfjörð Bjarmason (avar)。 (由Junio C Hamano—gitster—在commit a47fcfe中合并，2022年2月25日)

progress API:统一stop_progress{，_msg}()，修复trace2 bug 署名:Ævar Arnfjörð Bjarmason

我们在这里引入了9d81ecb(“进度:添加稀疏模式以强制100%完成消息”，2019-03-21,Git v2.22.0-rc0—合并在批次#5中列出)的潜艇错误。 “start_sparse_progress()”API只有在进度以“stop_progress()”结束时才会做正确的事情，而不是“stop_progress_msg()”。 该API的唯一用户使用“stop_progress()”，但是让我们通过将“stop_progress()”作为“stop_progress_msg()”的简单包装器来修复这个问题以及trace2问题。

对于较旧的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 repo:

$ (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.37 (Q3 2022)中，引入了一个新的bug()和BUG_if_bug() API，以便更容易地统一记录“检测多个错误并最终中止”模式。

这将是trace2输出的一部分，用于调试git-shell相关的问题。

参见 Ævar Arnfjörð Bjarmason （avar） 的提交 6d40f0a、提交 07b1d8f、提交 5b2f5d9、提交 53ca569、提交 0cc05b0、提交 19d7594（2022 年 6 月 2 日）。 （由 Junio C Hamano -- gitster -- 合并于 提交 4da14b5，2022 年 6 月 10 日）

usage.c:添加一个非致命的bug()函数来配合bug() 署名:Ævar Arnfjörð Bjarmason

Add a bug() function to use in cases where we'd like to indicate a runtime BUG(), but would like to defer the BUG() call because we're possibly accumulating more bug() callers to exhaustively indicate what went wrong. We already have this sort of facility in various parts of the codebase, just in the form of ad-hoc re-inventions of the functionality that this new API provides. E.g. this will be used to replace optbug() in parse-options.c, and the 'error("BUG:[...]' we do in a loop in builtin/receive-pack.c. Unlike the code this replaces we'll log to trace2 with this new bug() function (as with other usage.c functions, including BUG()), we'll also be able to avoid calls to xstrfmt() in some cases, as the bug() function itself accepts variadic sprintf()-like arguments. Any caller to bug() can follow up such calls with BUG_if_bug(), which will BUG() out (i.e. abort()) if there were any preceding calls to bug(), callers can also decide not to call BUG_if_bug() and leave the resulting BUG() invocation until exit() time. There are currently no bug() API users that don't call BUG_if_bug() themselves after a for-loop, but allowing for not calling BUG_if_bug() keeps the API flexible. As the tests and documentation here show we'll catch missing BUG_if_bug() invocations in our exit() wrapper.

技术/api错误处理现在包括在它的手册页:

的BUG、BUG、死亡、使用、错误和警告报告错误

技术/api错误处理现在包括在它的手册页:

bug (lower-case, not BUG) is supposed to be used like BUG but prints a "BUG" message instead of calling abort(). A call to bug() will then result in a "real" call to the BUG() function, either explicitly by invoking BUG_if_bug() after call(s) to bug(), or implicitly at exit() time where we'll check if we encountered any outstanding bug() invocations. If there were no prior calls to bug() before invoking BUG_if_bug() the latter is a NOOP. The BUG_if_bug() function takes the same arguments as BUG() itself. Calling BUG_if_bug() explicitly isn't necessary, but ensures that we die as soon as possible. If you know you had prior calls to bug() then calling BUG() itself is equivalent to calling BUG_if_bug(), the latter being a wrapper calling BUG() if we've set a flag indicating that we've called bug().

Technical /api-trace2现在在它的手册页中包括:

当BUG()、BUG()、error()、 调用Die()、warning()或usage()函数。

---

使用Git 2.38 (Q3 2022)，您甚至可以打印命令在运行时使用的配置值。

Git 2.39 (Q4 2022)增加了两个新的跟踪功能，“计时器”和“计数器”:

参见Jeff Hostetler (Jeff-Hostetler)的commit 8107162, commit 8ad5756, commit 24a4c45, commit 3124793, commit a70839c, commit 8e8c5ad, commit 5bbb925, commit 545ddca(2022年10月24日)。 (由Taylor Blau—Taylor—在commit e5be3c6中合并，2022年10月30日)

Trace2:添加秒表计时器 署名:Jeff Hostetler

Timers are an alternative to Trace2 Regions. Regions are useful for measuring the time spent in various computation phases, such as the time to read the index, time to scan for unstaged files, time to scan for untracked files, and etc. However, regions are not appropriate in all places. For example, during a checkout, it would be very inefficient to use regions to measure the total time spent inflating objects from the ODB (Object DataBase) from across the entire lifetime of the process; a per-unzip() region would flood the output and significantly slow the command; and some form of post-processing would be required to compute the time spent in unzip(). Timers can be used to measure a series of timer intervals and emit a single summary event (at thread and/or process exit).

Technical /api-trace2现在在它的手册页中包括:

"th_timer" This event logs the amount of time that a stopwatch timer was running in the thread. This event is generated when a thread exits for timers that requested per-thread events. { "event":"th_timer", ... "category":"my_category", "name":"my_timer", "intervals":5, # number of time it was started/stopped "t_total":0.052741, # total time in seconds it was running "t_min":0.010061, # shortest interval "t_max":0.011648 # longest interval } "timer" This event logs the amount of time that a stopwatch timer was running aggregated across all threads. This event is generated when the process exits. { "event":"timer", ... "category":"my_category", "name":"my_timer", "intervals":5, # number of time it was started/stopped "t_total":0.052741, # total time in seconds it was running "t_min":0.010061, # shortest interval "t_max":0.011648 # longest interval }

Technical /api-trace2现在在它的手册页中包括:

Stopwatch Timer Events Measure the time spent in a function call or span of code that might be called from many places within the code throughout the life of the process. static void expensive_function(void) { trace2_timer_start(TRACE2_TIMER_ID_TEST1); ... sleep_millisec(1000); // Do something expensive ... trace2_timer_stop(TRACE2_TIMER_ID_TEST1); } static int ut_100timer(int argc, const char **argv) { ... expensive_function(); // Do something else 1... expensive_function(); // Do something else 2... expensive_function(); return 0; } In this example, we measure the total time spent in expensive_function() regardless of when it is called in the overall flow of the program. $ export GIT_TRACE2_PERF_BRIEF=1 $ export GIT_TRACE2_PERF=~/log.perf $ t/helper/test-tool trace2 100timer 3 1000 ... $ cat ~/log.perf d0 | main | version | | | | | ... d0 | main | start | | 0.001453 | | | t/helper/test-tool trace2 100timer 3 1000 d0 | main | cmd_name | | | | | trace2 (trace2) d0 | main | exit | | 3.003667 | | | code:0 d0 | main | timer | | | | test | name:test1 intervals:3 total:3.001686 min:1.000254 max:1.000929 d0 | main | atexit | | 3.003796 | | | code:0

并且，仍然使用Git 2.39:

Trace2:添加全局计数器机制 署名:Jeff Hostetler

Add global counters mechanism to Trace2. The Trace2 counters mechanism adds the ability to create a set of global counter variables and an API to increment them efficiently. Counters can optionally report per-thread usage in addition to the sum across all threads. Counter events are emitted to the Trace2 logs when a thread exits and at process exit. Counters are an alternative to data and data_json events. Counters are useful when you want to measure something across the life of the process, when you don't want per-measurement events for performance reasons, when the data does not fit conveniently within a region, or when your control flow does not easily let you write the final total. For example, you might use this to report the number of calls to unzip() or the number of de-delta steps during a checkout.

Technical /api-trace2现在在它的手册页中包括:

"th_counter" This event logs the value of a counter variable in a thread. This event is generated when a thread exits for counters that requested per-thread events. { "event":"th_counter", ... "category":"my_category", "name":"my_counter", "count":23 } "counter" This event logs the value of a counter variable across all threads. This event is generated when the process exits. The total value reported here is the sum across all threads. { "event":"counter", ... "category":"my_category", "name":"my_counter", "count":23 }