git clone 在“检查连接性”处卡住了

Question

操作系统 - Windows 7专业版64位

Git for Windows - Git-1.9.0 - 使用Git bash

我突然发现“git fetch”出了问题。有时git.exe会出错，有时“git fetch”会一直挂起。

所以我决定从头开始重新安装。

我卸载了Git for Windows并重新安装它（接受所有默认设置），然后重新启动了计算机。创建了一个全新的文件夹，并执行以下操作：

$ git clone [e-mail]:[e-mail]/myproject.git
Cloning into 'myproject'...
Enter passphrase for key '/c/Users/myid/.ssh/id_rsa':
remote: Counting objects: 287209, done.
remote: Compressing objects: 100% (86467/86467), done.
remote: Total 287209 (delta 188451), reused 287209 (delta 188451)
Receiving objects: 100% (287209/287209), 168.89 MiB | 328.00 KiB/s, done.
Resolving deltas: 100% (188451/188451), done.
Checking connectivity...

它总是卡在“检查连接性”这一步。

我已经对计算机进行了病毒/木马等方面的扫描，没有发现任何威胁。

这种情况无论在工作地点还是在家中都会发生 - 因此可能不是因特网的问题。

我不确定该怎么继续或尝试下一步。

- FatherFigure

Answer 1

我从我的~/.ssh文件夹中删除了known_hosts文件，问题得到解决。现在一切正常。

- FatherFigure

---

这个文件夹位于哪里？ - Doug McClean

删除你的 .ssh 文件夹可能不是一个好主意，它保存了你所有的 ssh 密钥和配置。 - th3morg

Answer 2

这条消息与网络连接无关，而是关于检查每个对象是否连接到现有引用。

详细答案可以在superuser上找到。

- Jónás Balázs

---

乔纳斯是正确的。这里的“连通性”指的是图形连通性，因为在git中，所有提交都是一般N叉树图中的节点。未连接到任何内容的节点称为“孤立”提交，git gc可以安全地清理它们。 - Pyr3z

Answer 3

除了Git 2.34的提取优化之外，现在你还可以在Git 2.41（2023年第二季度）中使用一个新的"fetch.hideRefs"选项，用于从"rev-list --objects --stdin --not --all^(man)遍历中排除指定的引用，当单个存储库中存在许多无关的历史记录时，这是非常有用的。

请参见提交 c6ce27a（2023年2月12日），由Eric Wong（ele828）提交。
^{（由Junio C Hamano -- gitster --合并于提交 4d87411，2023年3月17日）}

fetch：支持hideRefs以加速连接检查

^{签名作者：Eric Wong}

With roughly 800 remotes all fetching into their own refs/remotes/$REMOTE/* island, the connectivity check1 gets expensive for each fetch on systems which lack sufficient RAM to cache objects.

To do a no-op fetch on one $REMOTE out of hundreds, hideRefs now allows the no-op fetch to take ~30 seconds instead of ~20 minutes on a noisy, RAM-constrained machine (localhost, so no network latency):

git -c fetch.hideRefs=refs \
    -c fetch.hideRefs='!refs/remotes/$REMOTE/' \
 fetch $REMOTE

1 git rev-list --objects --stdin --not --all --quiet --alternate-refs^(man)

git rev-parse现在在其手册页面中包含以下内容：

--exclude-hidden=[fetch|receive|uploadpack]

通过查阅适当的fetch.hideRefs、receive.hideRefs或uploadpack.hideRefs配置以及transfer.hideRefs，不包括由git-fetch、git-receive-pack或git-upload-pack隐藏的引用。

rev-list-options现在在其手册页面中包含类似的选项。

- VonC

Answer 4

尝试使用设置环境变量GIT_CURL_VERBOSE=1运行git，以查看发生了什么。

- zgyarmati

---

现在我收到了这个错误信息：“正在检查连接性...致命错误：远程没有发送所有必要的对象”，接下来是“文件 'myproject/.git/objects/pack/pack-ce829859ab3615e4cbcb421746d0a59b305a6ac8.idx' 的取消链接失败。我应该再试一次吗？（y/n）” - FatherFigure

Answer 5

这应该会在 Git 2.34（2021年第四季度）中得到改善，其中处理“git fetch”^(man)代码路径中大量引用的代码已经被优化。

请查看提交 caff8b7, 提交 1c7d1ab, 提交 284b2ce, 提交 62b5a35, 提交 9fec7b2, 提交 47c6100, 提交 fe7df03 (2021年9月1日) 由Patrick Steinhardt (pks-t)提交。
^{(由Junio C Hamano -- gitster --合并于提交 deec8aa, 2021年9月20日)}

fetch：如果我们已经拥有所有对象，避免进行第二次连接检查。

补充说明：Patrick Steinhardt签署。

当获取引用时，我们执行两个连接性检查：

第一个检查是这样做的，以便在我们已经拥有更新后的引用集所引用的所有对象的情况下跳过获取引用。

第二个检查验证我们在获取了对象之后是否拥有所有对象。

我们总是执行两个连接性检查，但是如果第一个连接性检查已经注意到我们已经拥有所有本地可用的对象，则这是浪费的。

如果我们已经拥有所有对象，请跳过第二个连接性检查。当在具有约2.3M个引用的存储库中进行镜像提取且提取存储库已经拥有所有对象时，这会使我们获得很好的加速：

基准测试#1：HEAD〜：git-fetch 时间（平均值±σ）：30.025秒±0.081秒[用户：27.070秒，系统：4.933秒] 范围（最小...最大）：29.900秒...30.111秒5次运行

基准测试#2：HEAD：git-fetch 时间（平均值±σ）：25.574秒±0.177秒[用户：22.855秒，系统：4.683秒] 范围（最小...最大）：25.399秒...25.765秒5次运行

概要 'HEAD：git-fetch'运行 比'HEAD〜：git-fetch'快1.17±0.01倍

- VonC

Answer 6

你应该执行 "git prune"。

- Nikolai

---

指出为什么这会有帮助会很有用。 - mjs

我同意这会很有帮助，但是目前我只知道它可以工作。 - Nikolai