git count-objects警告：没有相应的.pack：

Question

git count-objects -v发出的警告是什么意思？谷歌只给了我git的来源。

warning: no corresponding .pack: .git/objects/pack/pack-fdd1d6e3161128d4fe4b38849cf0.idx
...  (many lines of the same warning)
count: 4715
size: 37151
in-pack: 426048
packs: 22
size-pack: 656437
prune-packable: 137
garbage: 92
size-garbage: 5893

这是否意味着可以压缩这些对象，如this answer?

所暗示的那样

如何判断我是应该重新包装还是gc我的存储库（显然重新包装和gc之间有区别）？它有必要还是有害的？

为什么git有这么多行话！

Answer 1

这可能是因为打包文件太大。

在Git 2.30（Q1 2021）之前，该代码尚未准备好处理大于4GB的压缩包.idx。

请参见commit 81c4c5c的commit 9bb4542，commit 33bbc59，commit a9bc372，commit f86f769，Jeff King (peff)（2020年11月13日）。 ^{（由Junio C Hamano -- gitster --在commit fcf26ef中合并，2020年11月25日）}

pack：使用size_t存储包.idx的字节偏移量

^{签名人：杰夫·金}

我们有时将偏移量存储为.idx包中的文件的“无符号长”，但是包.idx文件的mmap大小可能超过4GB。

这在Linux等LP64系统上就足够了，但在Windows等LLP64系统上就太小了，在Windows上“ unsigned long”仍然只有32位。

让我们使用size_t,，它是内存缓冲区中偏移量的更好类型。

这会影响git fsck

fsck：在大于4GB的idx文件上正确计算校验和

^{签名人：杰夫·金}

在检查.idx文件的尾部校验和哈希时，我们将整个缓冲区（减去尾部哈希）传递给对the_hash_algo->update_fn()的单个调用。
但是我们将其强制转换为“ unsigned int”。
这来自c4001d92be（“当我们真正要表示文件偏移时使用off_t。”，2007年3月6日，Git v1.5.1-rc1-merge）。该提交开始将index_size变量存储为off_t,，但是从那时起，我们的mozilla-sha1实现被限制为较小的大小。
大概是强制转换是一种说明我们期望.idx文件较小的方式，因此我们不需要循环（就像我们对任意大的.pack文件所做的那样）。顺便说一句，它仍然是错误的，因为mozilla函数实际上采用了带符号的int。

这些天，我们的哈希更新函数定义为采用size_t,，因此我们可以直接传递整个缓冲区。演员表实际上造成了越野车的截断！

虽然我们在这里，但我们首先将令人困惑的off_t变量删除。无论如何，我们不是从文件系统获取大小，而是从p->index_size,（即size_t）获取大小。实际上，通过删除重复p->index_size,的局部变量，我们可以使代码更具可读性，而可以存储一个实际索引数据的大小（减去尾随的哈希值）。 （复制到剪贴板）