56

当从 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 连接到我已经完成工作的服务器没有问题。

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

4

6 回答 6

24

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

于 2017-01-19T09:21:02.253 回答
11

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

Host *

ServerAliveInterval 60

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

于 2013-07-05T18:26:31.367 回答
9

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

于 2012-11-07T17:06:39.077 回答
2

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

请参阅Jeff King ( ) 的提交1435889 （ 2019 年 3 月 3 日）和提交 37c8001（2019 年 3月 5 日）。（由Junio C Hamano 合并 -- --在提交 27cdbdd中，2019 年 3 月 20 日）peff
gitster

fetchSIGPIPE:网络运行时忽略

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

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

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

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

于 2019-03-24T01:03:42.913 回答
1

重置 git 凭据对我有用。

git config --global credential.helper store
于 2021-05-23T09:39:30.157 回答
-26

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

$ git init

它应该有帮助

于 2015-12-15T16:10:15.020 回答