Question

已经多次询问过有关此问题的问题：

我有同样的错误，但我正在寻找一种有效的诊断方法来得出它的网络问题或git（之后不需要修复它）。

问题描述

使用的Git版本是1.8.4.msysgit.0

在其中一台计算机上使用git守护程序托管的裸仓库

git daemon --verbose --export-all --enable=receive-pack --base-path="C:\path\to\git_remotes"
其他计算机通过git协议使用该repo
其他计算机上的人（所有在同一子网中）有时可以成功clone/pull/fetch/push。其他时候他们会收到以下错误

enter image description here

即使在失败的情况下，也始终在启动git守护程序的shell中检测到它们的操作。来自守护程序的本地克隆/ pull / fetch / push始终

更新：git fsck

在本地仓库（总是有效的）。有一个悬垂的斑点。在裸仓库（与本地仓库在同一台计算机上）。没有悬空或提交。

在其他非裸仓（在通过克隆裸仓库创建的其他计算机上）：

它们都不起作用。

上面的错误是什么意思，可以用wireshark（它提到一些包标题）来诊断它是否是网络或git错误？

Answer 1

有几种方法可以调试问题。因为它声称包标题是错误的，所以它似乎可能是服务器端问题。假设您在unix风格的操作系统下运行，可以尝试运行：

GIT_TRACE=2 git fetch

要了解更多关于幕后情况的信息。它可以更好地指示事情失败的地方。但是，要查看实际的数据传输，您应该尝试：

GIT_TRACE=2 GIT_TRACE_PACKET=2 git fetch

那会丢弃在线上传输的内容。这将是识别客户端和服务器之间传递的任何奇怪内容的地方。

所有这些都说明了一个错误，其中git prune（重新打包时自动执行）会意外打印到stdout并打破包协议。这是在git 1.7.12.1中修复的，所以答案可能只是升级Git。

如果您在服务器上运行Ubuntu，可以添加git-core PPA并从那里获取最新的稳定版本。有关如何操作的说明，请访问网站。

Answer 2

注意：除了GIT_TRACE=2 GIT_TRACE_PACKET=2之外，git fetch本身在git 2。8（2016年3月）中会更加冗长

将传输详细程度传递给git_connect

在TCP连接代码中有一些“现在我正在做这件事”的进度消息可以通过在代码内部设置一个详细选项来触发，但是“git fetch -v”并且朋友们从未通过详细信息选项到该代码路径。

因此，您可以将git fetch -v添加到调试选项列表中。

将传输详细程度传递给git_connect