git - 重新打包存储库对大型二进制文件有用吗？

Question

我正在尝试将大量历史记录从 Perforce 转换到 Git，并且一个文件夹(现在是 git 分支)包含大量大型二进制文件。我的问题是我在运行 git gc --aggressive 时内存不足。

我的主要问题是重新打包存储库是否可能对大型二进制文件产生任何有意义的影响。再压缩 20% 会很棒。 0.2% 不值得我付出努力。如果没有，我会按照建议跳过它们 here .

对于背景，我成功地使用 git p4 创建了我满意的状态的存储库，但这在幕后使用了 git fast-import 所以我想要在正式发布之前优化存储库，并且确实使任何提交自动触发缓慢的 gc --auto。目前裸机状态约为 35GB。

从概念上讲，有问题的二进制文件似乎是嵌入式设备中使用的供应商固件。我认为在 400-700MB 范围内大约有 25 个，在 20-50MB 范围内可能还有几百个。它们可能是磁盘镜像，但我不确定。随着时间的推移，出现了各种版本和文件类型，我经常看到 .zip、tgz 和 .simg 文件。因此，我希望原始代码有明显的重叠，但我不确定此时实际文件看起来有多相似，因为我相信这些格式已经被压缩了，对吧？

这些二进制文件包含在一个(旧的)分支中，该分支很少会被过度使用(质疑版本控制是否有效，但超出范围)。当然，该分支的性能不需要很好。但我希望存储库的其余部分是合理的。

欢迎提供有关优化打包或内存管理的其他建议。我承认我并不真正理解在链接问题上讨论的各种 git 选项。我也不真正了解 --window 和 --depth 标志在 git repack 中的作用。但主要问题是二进制文件本身的重新打包是否在做任何有意义的事情。

Answer 1

My primary question here is whether repacking the repository is likely to have any meaningful effect on large binaries.

这取决于它们的内容。对于您特别概述的文件:

I see .zip, tgz, and .simg files frequently.

Zipfiles 和 tgz(gzipped tar archive)文件已经被压缩并且有可怕的(即高)Shannon entropy值——这对 Git 来说很糟糕——并且不会相互压缩。 .simg 文件可能是(我不得不在这里猜测)Singularity disk image files ;它们是否以及如何被压缩，我不知道，但我会假设它们是。 (一个简单的测试是将一个提供给压缩器，例如 gzip，看看它是否收缩。)

As such, I'd expect the raw code to have significant overlap, but I'm not sure how similar the actual files appear at this point, as I believe these formats have already been compressed, right?

没错。因此，矛盾的是，将它们未压缩存储在 Git 中最终会导致更大的压缩。 (但打包可能需要大量内存。)

If [this is probably futile], I'll have them skipped over as suggested here.

这将是我在这里的第一个冲动。 :-)

I admit I don't really understand the various git options being discussed on the linked question. Nor do I really understand what the --window and --depth flags are doing in git repack.

各种限制令人困惑(而且很多)。同样重要的是要意识到它们不会在克隆时被复制，因为它们在 .git/config 中，这不是提交的文件，所以新的克隆不会拾取它们。 .gitattributes 文件被复制到克隆上，新克隆将继续避免打包不可打包的文件，因此这是更好的方法。

(如果您想深入了解细节，您会在 the Git technical documentation 中找到一些内容。这并没有准确讨论窗口大小，但它与 Git 使用多少内存来内存映射对象有关选择可能相互压缩良好的对象时的数据。有两个:一个用于一个包文件上的每个单独的 mmap，一个用于所有包文件上的总聚合 mmap。您的链接中未提及:core.deltaBaseCacheLimit ，这是用于保存 delta 基数的内存量——但要理解这一点，您需要理解 delta 压缩和 delta 链，¹ 并阅读相同的技术文档。请注意 Git将默认不尝试打包任何大小超过 core.bigFileThreshold 的文件对象。各种 pack.* 控件有点复杂:打包是多线程完成的尽可能利用所有 CPU，并且每个线程都可以使用大量内存。限制数量 o f threads 限制总内存使用:如果一个线程要使用 256 MB，则 8 个线程可能会使用 8*256 = 2048 MB 或 2 GB。位图主要是为了加快从繁忙的服务器中获取数据的速度。)

---

¹它们并没有那么复杂:当一个对象说“获取对象 XYZ 并应用这些更改”，但对象 XYZ 本身说“获取对象 PreXYZ 并应用这些更改”时，就会出现增量链.对象 PreXYZ 也可以带另一个对象，依此类推。 delta base 是此列表底部的对象。