Git fetch/pull/clone 在接收对象时挂起

Posted 2023-02-21

【中文标题】Git fetch/pull/clone 在接收对象时挂起

【英文标题】：Git fetch/pull/clone hangs on receiving objects

【发布时间】：2012-08-10 02:06:40

【问题描述】：

当从 git 存储库中获取或拉取，或克隆存储库时，我明白了这一点：

remote: Counting objects: 6666, done.
remote: Compressing objects: 100% (5941/5941), done.
Receiving objects:  23% (1534/6460), 11.68 MiB | 23 KiB/s  

然后挂起。 23%/对象的数量不是一个给定的，它似乎从个位数到 60 年代不等。列出的下载速度也冻结了——它不像是慢慢地爬到零。

我坐在旁边的那个人没有问题，所以这不是路由器问题。我们将 beanstalk 用于我们的工作存储库，但我有来自 beanstalk 和 github 的问题（尽管有时似乎 github 会完成）。

这个问题似乎是在升级到 Mountain Lion 并更新 Xcode 后才出现的。我已经擦除了 git（包括 XCode）并尝试使用自制软件安装它。那没有用，所以我将其删除并尝试使用他们提供的 Mac 安装包，但也没有解决问题。

Beanstalk 为 git 存储库提供 SSH url，但我通过 SCP 或 SSH 连接到我已经完成工作的服务器没有任何问题。

这正在扼杀我的工作流程，因此我们将不胜感激！

【问题讨论】：

您在擦除 git 时尝试新的存储库克隆，还是每次都是同一个本地存储库？

忘了说——它既可以获取已经存在的资源，也可以尝试克隆新的存储库

相同的错误是否适用于每个 git 存储库，或者只是这个特定的代码库？例如，如果您克隆git's source,，它是否表现出类似的症状？

这是因为另一个应用程序吗？ （例如，一种防病毒软件，例如openforum.sophos.com/t5/Sophos-Anti-Virus-for-Mac-Home/…），或者您是否有一个组件已知在其当前版本中与 Mountain Lion 一起挂起（请参阅roaringapps.com/search:site/q/hang）

我确实有 Sophos，但已将其删除。我已经完成并清理了所有内容，因此没有打开其他应用程序，并且我尽可能多地清理了后台进程。出现同样的问题。

【参考方案1】：

尝试检查您的网络连接。也许路由表中有垃圾。可能是路由器上的端口损坏或计算机的网络接口问题。尝试 ping 您正在克隆 git repo 的服务器，可能您的计算机和此服务器之间的链接不稳定。

【讨论】：

我遇到了同样的问题，你的建议奏效了。我 ping 了 github.com -t 并克隆开始接收对象。

不幸的是，这对我不起作用。 github 上任何 repo 的克隆仍然停留在一定百分比...

由于某种原因，您的 MTU 可能设置得太高。尝试暂时降低其中一台机器的 MTU，以确定原因是否与此有关。

【参考方案2】：

看起来类似于我的问题。在一段时间后，Git 似乎挂在了 fetch 或 push 上。 我可以建议你输入~/.ssh/config:

Host *

ServerAliveInterval 60

我有一个 MBP 和山狮。我希望这个超时是你问题的原因。 （大约三十或四十分钟后，我注意到它还在继续。）

【参考方案3】：

首先尝试通过键入初始化 git 存储库文件夹

$ git init

应该有帮助

【讨论】：

git clone 自动调用git init。

【参考方案4】：

VMware on NAT 对我有这个问题。将其更改为 Bridged（复制状态） 解决了该问题。

【讨论】：

谢谢。我不敢相信我在尝试解决 Github 服务器限制时浪费了这么多时间，而实际上解决方案非常简单......我的问题发生在克隆 CocoaPods 规范 repo 时，所以我认为它与 ***.com/questions/23755974/… 有关...这不是，只是网络问题。

【参考方案5】：

在 Mac 上，使用 Git 2.22（2019 年第二季度）， git fetch 应该更能抵抗此类问题：在“git fetch”被 SIGPIPE（例如 OSX）杀死的平台上，upload-pack 在检测到错误后挂断的另一端可能会导致“git fetch”因信号而死，从而导致不稳定的测试。 “git fetch”现在在其操作的网络部分忽略 SIGPIPE（这不是问题，因为我们检查了 write(2)s 的返回状态）。

参见commit 1435889（2019 年 3 月 3 日）和 commit 37c8001（2019 年 3 月 5 日）Jeff King (peff)。^{（由 Junio C Hamano -- gitster -- 合并到 commit 27cdbdd，2019 年 3 月 20 日）支持>}

fetch：网络运行时忽略SIGPIPE

默认的SIGPIPE 行为对于生成的命令很有用 大量输出：如果我们输出的接收器消失了，我们将 异步通知停止生成它（通常通过杀死 程序）。

但是对于像fetch 这样的命令，它主要关注的是 接收数据并将其写入磁盘，可能会出现意外的SIGPIPE 尴尬的。我们已经在检查所有write() 的返回值 呼叫，并因信号而死，带走了我们优雅的机会 处理错误。

在 Linux 上，我们通常在 fetch 期间根本看不到 SIGPIPE。如果 另一端网络连接挂断，我们会看到ECONNRESET。 但在 OS X 上，我们得到一个SIGPIPE，进程被杀死。

让我们在获取的网络部分忽略SIGPIPE，这将 导致我们的write() 返回EPIPE，从而为我们提供一致的行为 平台。

【参考方案6】：

重置 git 凭据对我有用。

git config --global credential.helper store