如果 git fetch 中途取消，它会恢复吗？

Question

有时获取任何 git 存储库（通过执行“git fetch repository_URL”）可能需要几个小时，具体取决于存储库的大小和网络速度。

如果由于某种原因，用户在中途取消了获取，然后稍后尝试在他/她取消最后一次获取的完全相同的环境中获取相同的存储库，那么获取将如何工作？

它会从中断的地方继续获取吗？

Answer 1

没有（2015 年）或者可能很快（2018 年第四季度），git clone/fetch/pull 操作没有“恢复”功能。

从那时起：

• 2018 年第四季度，Git 2.18 and 2.19 introduce a Wire v2 protocol。
• GitLab will support it starting Oct. 2018。

---

2015 年：

唯一的选择，mentioned in this thread，是 gitolite（这是一个管理 ACM 的 perl 脚本——您的存储库的访问控制级别，以及提供围绕 git 访问的其他实用程序）

gitolite 可以配置为更新“Git 包”（参见 git-bundle manual) 然后可以通过 rsync 或 HTTP 协议，然后可以使用 rsync 客户端下载 支持恢复的 HTTP 客户端。

使用此技术可以使“下载所有内容”和“从下载的内容中创建一个 repo”步骤不同，并且可以使用任意次数的尝试来执行第一步。

缺点很明显：

1. 这需要在服务器端进行特殊设置。
2. 目前尚不清楚如果有人设法更新存储库会发生什么 当有人下载​​它的捆绑包时，或者更新发生时 在相邻的下载尝试之间。

---

关于git clone/fetch（“How to complete a git clone for a big project on an unstable connection?”中提到）的可恢复功能，最近在git mailing list上有一个讨论（2016年3月）。

• 一种方法是让服务器生成可以加载的包（使用wget -c! 恢复）并添加到本地存储库（因为包是一个文件，您可以从中克隆, 就好像它是一个 git repo)。
  见“Cloning Linux from a bundle”

即：

wget -c https://cdn.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/clone.bundle
git bundle verify clone.bundle
...
clone.bundle is okay
git clone clone.bundle linux
#Now, point the origin to the live git repository and get the latest changes:
cd linux
git remote remove origin
git remote add origin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git pull origin master

• 另一种方法是实际实现可恢复的git clone,discussed in this thread

我们可以通过做一些混合来实现可恢复克隆 聪明而笨拙的 HTTP 协议。

1. A git clone 最终调用到传输层，并且 git-remote-curl 将探测信息/克隆 URL；如果资源 加载失败，一切都通过传统的代码路径。

2. 当git-remote-curl 检测到支持哑克隆时，它会执行 “重试直到成功完全下载包数据”舞蹈 在内部，暂时更新远程跟踪参考，然后 假装好像它被要求进行增量提取。如果这 没有die()就成功了，大家都很开心。

3. 如果上述步骤 3. 出于某种原因必须die()（包括 不耐烦按 CTRLC），离开$GIT_DIR，下载.info 文件并部分下载.pack 文件。
   告诉用户可以恢复克隆以及如何恢复。

注意这是一个可恢复的克隆，not a resumable fetch：

初始“克隆”和后续增量“获取”是正交问题。

因为建议的“克隆”更新比 建议更改为“获取”，即

• 传输的数据量要大得多，因此 在较差的网络环境下网络超时的可能性是 更高，需要恢复更大。
• 不仅该方法使“克隆”可恢复并提供帮助 客户端，它可以帮助服务器将批量传输卸载到 CDN。

它对现有代码的破坏要小得多，即

• 我们不必悲观打包过程，只需丢弃 生成的大部分字节，如建议的方法 用于“获取”。
• 需要新代码的区域隔离良好，切换到 新协议在交换的早期发生，没有共享 现有代码路径的代码；这些特性降低了风险 引入回归。

为了避免新协议中的仅 HTTP 功能，建议使用“v2”协议，让双方在 ref 广告之前交换能力。然后，客户端在看到服务器的可恢复 URL 后，就知道是否继续进行广告。
请参阅 2017 年 7 月的stefanbeller/gitprotocol2-10。