git fetch 实现断点续传
内容提要
文章介绍了一种实现Git断点续传的方法。针对网络不稳定导致下载中断的问题，作者通过分步获取提交和树对象，再分批回填缺失的blob对象，并利用Git的lazy fetch特性，实现了高效恢复。文中还分享了踩坑经验，并提供了脚本安装方式。
延伸解读
核心原理：利用 partial clone 与 lazy fetch
文章通过 `--filter=blob:none` 实现 partial clone，先只拉取 commit 和 tree 对象，再根据缺失列表分批回填 blob。关键点在于利用 Git 的 lazy fetch 机制，通过 `--filter=blob:none` 和 `--stdin` 批量请求缺失对象，同时用 `fetch.negotiationAlgorithm=noop` 避免服务器发送薄包，确保完整传输。
踩坑提醒：rev-list 与 cat-file 的差异
作者指出 `git fetch origin <blobsha>` 会打印错误但实际下载成功，原因是 `cat-file` 会触发 lazy fetch 拉取数据，而 `rev-list --missing=print` 不会。因此，计算缺失集合时应使用 `rev-list`，避免误判。
适用场景与局限
该方法主要针对网络不稳定的环境，通过分批下载降低中断风险。但作者也提到，随着 AI 辅助编程的普及，这类脚本可能逐渐失去必要性，因为开发者可以随时让 AI 生成临时脚本。此外，脚本目前未支持多线程并发，仍有优化空间。
Q&A
Git fetch 断点续传的原理是什么？
原理是分步获取：先用 `git fetch --filter=blob:none --depth=1` 只拉取 commit 和 tree 对象（传输量小），然后用 `rev-list --objects --missing=print` 计算缺失的 blob 对象，再分批（每批500个）回填缺失的 blob，每轮重算缺失并只补缺的，从而实现断点续传。
如何安装和使用 git-fr 脚本？
将 fr.sh 放到 PATH 中（如 ~/.local/bin/git-fr），然后就可以使用 `git fr` 命令。或者通过 `git config --global alias.fr '!<绝对路径>/fr.sh'` 设置别名。
为什么普通的 git fetch 在断网后无法续传？
因为普通的 `git fetch origin main --depth=1` 一次只下载一个 pack，包含所有缺失对象，如果网络中断，整个下载就失败，需要从头开始。
在实现断点续传时踩过哪些坑？
踩过的坑包括：1. 使用 `git fetch origin <blobsha>` 会打印错误信息，但对象实际已下载，因为 `cat-file` 会拉数据而 `rev-list --missing=print` 不会；2. 普通 fetch 拿到的 pack 是薄包，服务器可能不发送对象；3. 通过 GIT_TRACE 发现 git 原生 lazy fetch 实际执行的命令，关键参数是 `fetch.negotiationAlgorithm=noop` 和 `--filter=blob:none`。
git 原生 lazy fetch 是如何工作的？
git 原生 lazy fetch 在访问缺失对象时自动触发，实际执行的命令类似：`git -c fetch.negotiationAlgorithm=noop fetch origin --no-tags --no-write-fetch-head --recurse-submodules=no --filter=blob:none --stdin`。关键点：`fetch.negotiationAlgorithm=noop` 避免薄包化，`--filter=blob:none` 显式声明的 want 会绕过过滤器直接发送，`--stdin` 支持批量 want 列表。
为什么使用 `--filter=blob:none` 和 `fetch.negotiationAlgorithm=noop` 能实现断点续传？
`--filter=blob:none` 使得初始 fetch 只获取 commit 和 tree，避免下载大 blob；`fetch.negotiationAlgorithm=noop` 让服务器无法进行薄包化，从而必须发送完整对象，这样后续分批 fetch 缺失 blob 时，服务器会直接发送请求的对象，实现断点续传。
