19

如果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) 放入一个新的本地存储库。但是有没有更好（更快）的解决方案？

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

4

7 回答 7

11

试试这些命令：

git fsck
git gc
于 2012-10-13T07:59:29.003 回答
7

*.pack.temp在.git/objects/pack您的本地存储库中找到一个。然后找到一个.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
于 2015-02-02T19:00:21.987 回答
1 
man git-fsck

说要使用 rsync ：

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

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

为我工作

于 2013-03-29T17:29:27.207 回答
0

使用 Git 2.30（2021 年第一季度）的清理应该更简单：“ git fetch” （man）被杀死可能会留下一个 pack-objects 进程，仍在计算以找到一个好的压缩，浪费周期。

这已得到纠正。

请参阅Jeff King ( ) 的提交 309a402（2020 年 12 月 1 日）。（由Junio C Hamano 合并 -- --在提交 f3a112a中，2020 年 12 月 3 日）peff
gitster

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

签字人：杰夫·金

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

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

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

使用此补丁，pack-objects立即退出upload-pack。

于 2020-12-05T00:12:20.523 回答
-1

你能跑吗：

git reset --hard <some prior commit>

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

git reset --hard HEAD

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

于 2012-05-20T10:14:04.457 回答
-1

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

于 2015-01-29T22:36:13.477 回答
-2

你试过清理回购吗？

git gc

被警告，因为上面的命令也会清理 reflog 的东西。

于 2012-05-21T07:58:07.413 回答