我怎么能有一些关于git/git-shell的调试信息?

我遇到了一个问题,user1可以毫无问题地克隆一个存储库,而user2只能克隆一个空的存储库。我设置了GIT_TRACE=1,但是没有任何有用的提示。

最后,经过长时间的尝试和错误,发现这是一个文件的权限问题。适当的错误消息可以避免此问题。


当前回答

调试

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版本(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有一个相当完整的嵌入式跟踪集,您可以使用它来调试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
...

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

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

在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_TRACE=1 git pull origin master