git 计数对象警告 : no corresponding . 包:

Question

git count-objects -v 发出的这个警告是什么意思？ Google 只给了我 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 我的存储库(显然 repack 和 gc 之间有区别)？它是完全必要的还是有害的？

为什么 git 有这么多行话!

Answer 1

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

在 Git 2.30(2021 年第一季度)之前，代码不准备处理大于 4GB 的 pack .idx 文件。

参见 commit 81c4c5c , commit 9bb4542 , commit 33bbc59 , commit a9bc372 , commit f86f769 (2020 年 11 月 13 日)Jeff King (peff) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit fcf26ef ，2020 年 11 月 25 日)}

pack:use size_t to store pack .idx byte offsets

^{Signed-off-by: Jeff King}

We sometimes store the offset into a pack .idx file as an "unsigned long", but the mmap'd size of a pack .idx file can exceed 4GB.

This is sufficient on LP64 systems like Linux, but will be too small on LLP64 systems like Windows, where "unsigned long" is still only 32 bits.

Let's use size_t, which is a better type for an offset into a memory buffer.

这会影响 git fsck

fsck: correctly compute checksums on idx files larger than 4GB

^{Signed-off-by: Jeff King}

When checking the trailing checksum hash of a .idx file, we pass the whole buffer (minus the trailing hash) into a single call to the_hash_algo->update_fn().
But we cast it to an "unsigned int".
This comes from c4001d92be ("Use off_t when we really mean a file offset.", 2007-03-06, Git v1.5.1-rc1 -- merge). That commit started storing the index_size variable as an off_t, but our mozilla-sha1 implementation from the time was limited to a smaller size.
Presumably the cast was a way of annotating that we expected .idx files to be small, and so we didn't need to loop (as we do for arbitrarily-large .pack files). Though as an aside it was still wrong, because the mozilla function actually took a signed int.

These days our hash-update functions are defined to take a size_t, so we can pass the whole buffer in directly. The cast is actually causing a buggy truncation!

While we're here, though, let's drop the confusing off_t variable in the first place. We're getting the size not from the filesystem anyway, but from p->index_size, which is a size_t. In fact, we can make the code a bit more readable by dropping our local variable duplicating p->index_size, and instead have one that stores the size of the actual index data, minus the trailing hash.'(Copied to the clipboard)