如何修复被中断的 git fetch 破坏的 git 存储库？

Question

如果git fetch 被中断，例如被 Ctrl-C 或连接问题引起，那么之后git fetch 和git pull 将无法工作。

user@computer:~/code/openttd-git$ git fetch
^C
user@computer:~/code/openttd-git$ git fetch
error: Unable to find 22d90742fc79a9011fb86ee03d8aeea66bc12657 under http://git.openttd.org/openttd/trunk.git
Cannot obtain needed object 22d90742fc79a9011fb86ee03d8aeea66bc12657
error: Fetch failed.

我相信这与存储库无关。使用git clone 将此损坏的本地存储库的副本创建到新的本地存储库中并不能解决此问题。到目前为止，我知道的唯一解决方案是将git clone 整个远程存储库（origin/master）放到一个新的本地存储库中。但是有没有更好（更快）的解决方案？

Debian bug report 的最后一条消息来自 2011 年 2 月。这是我遇到的相同错误还是已经有修复或任何解决方案或解决方法？我的 git 版本是 1.7.10。

Answer 1

试试这些命令：

git fsck
git gc

Answer 2

在您的本地存储库中的.git/objects/pack 中找到*.pack.temp。然后找到一个具有相同基本名称的.idx 文件，并将它们都移开（或删除它们，但安全总比抱歉好）。重新运行git fetch，它应该可以工作（嗯，它对我有用）。

例如：

% git fetch
error: Unable to find a4fb0b54b2609df8a1ee4b97c268d205fc5bf9f1 under https://www.example.com/~someuser/something.git
Cannot obtain needed object a4fb0b54b2609df8a1ee4b97c268d205fc5bf9f1
error: fetch failed.

% ls -l .git/objects/pack
total 65872
-rw-r--r-- 1 someuser someuser    64072 Feb 12  2014 pack-2e31e66e67d8596f1193bbbc06c87293900c6e45.idx
-rw-r--r-- 1 someuser someuser    16920 Jul 21  2013 pack-3d76e0bf6c67d71913efc0711d56f04c7f79b95d.idx
-rw-r--r-- 1 someuser someuser    62224 Feb 11  2014 pack-74107fa80989df6619479874d94b5f8ed010fd2f.idx
-rw-r--r-- 1 someuser someuser    96552 Oct 30 22:55 pack-bb75633331ea0e74d4d3cb29f7660e1ba00fb899.idx
-rw-r--r-- 1 someuser someuser    73228 Mar  6  2014 pack-de0c1bcf3550cd7a2fd0c5a981bc17d15f1144c0.idx
-r--r--r-- 1 someuser someuser   129144 Feb  2 18:57 pack-ffb25d036dea040923468e2de07023f9b497aeb7.idx
-r--r--r-- 1 someuser someuser 46413554 Feb  2 18:57 pack-ffb25d036dea040923468e2de07023f9b497aeb7.pack
-r--r--r-- 1 someuser someuser   129312 Feb  2 19:10 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx
-rw-r--r-- 1 someuser someuser 20450545 Feb  2 19:09 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack
-rw-r--r-- 1 someuser someuser   129312 Feb  2 18:36 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx
-rw-r--r-- 1 someuser someuser  9863168 Feb  2 18:37 pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack.temp

% mv .git/objects/pack/pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.idx /tmp/
% mv .git/objects/pack/pack-ffbdfa2c676aaf392ea722cb68eaa87e45af092c.pack.temp /tmp/
% git fetch
From https://www.example.com/~someuser/something
   3288ab9..a4fb0b5  master     -> origin/master

Answer 3

man git-fsck

说要使用 rsync ：

您必须在备份或其他存档中找到的任何损坏的对象 （即，您可以删除它们并 与其他站点进行 rsync，希望其他人拥有您损坏的对象）。

rsync -av user@host:repo/.git ./.git

为我工作

Answer 4

使用 Git 2.30（2021 年第一季度）的清理应该更简单：“git fetch”^(man) 被杀死可能会留下一个打包对象进程，仍在计算以找到一个良好的压缩，浪费循环。

这已得到纠正。

参见 Jeff King (peff) 的 commit 309a402（2020 年 12 月 1 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit f3a112a，2020 年 12 月 3 日）}

upload-pack: 在信号或退出时杀死 pack-objects 助手

^{签字人：杰夫·金}

我们生成了一个外部打包对象进程来实际将对象发送到远程端。如果我们在此过程中被信号杀死，那么 pack-objects 可能会继续运行。一旦它开始为包生成输出，它将看到写入上传包失败并自行退出。
但在此之前，它可能会在遍历对象图、压缩增量等方面做大量工作，这些都将毫无意义。因此，一旦我们知道调用者不会读取结果，我们就一定要杀死。

这里没有测试，因为它本质上是活泼的，但这里有一个简单的复制是在像 linux.git 这样的大型 repo 上：

• 确保您没有打包位图（因为它们会使枚举阶段快速进行）。对于linux.git，在我的机器上遍历整个图表大约需要 30 秒左右。
• run "git clone --no-local -q . dst^(man); "-q" 很重要，因为如果pack-objects 正在向upload-pack 写入进度（通过边带多路复用到客户端），然后它会很快注意到写入 stderr 失败
• 在另一个终端中杀死客户端克隆进程（不要使用 ^C，因为这会将SIGINT 发送到所有进程）
• 运行“ps au | grep git”或类似命令以观察 upload-pack 在 5 秒内死亡（它会发送一个 keepalive 通知客户端已经离开）
• 但您仍会看到pack-objects 在遍历和增量压缩阶段消耗 100% 的 CPU（和 1GB+ 的 RAM）。它会在开始写入包时立即退出（当它会注意到 upload-pack 消失时）。

有了这个补丁，pack-objects 会在upload-pack 退出时立即退出。

Answer 5

你能跑吗：

git reset --hard <some prior commit>

理论上，如果你刚刚运行git fetch，你应该能够：

git reset --hard HEAD

这应该放弃由中断的提取操作引起的更改，将您的存储库返回到之前的状态。此时您应该能够重新运行fetch 操作。

Answer 6

存储库很可能已损坏。在服务器上运行git fsck 和git gc 可能会解决它。克隆到一个单独的目录并从该目录中提取也将为您提供提交。之后 git fetch 将起作用，因为它只更新 refs 而不必获取任何对象。

Answer 7

您是否尝试过清理存储库？

git gc

请注意，上述命令也会清除 reflog 内容。