如何使用 git repack -a -d --depth=250 --window=250

Question

我已经看到 git gc --aggressive --prune 和 git repack -a -d --depth=250 --window=250 被推荐用于减小不需要较长本地历史记录的本地 .git 文件夹的大小。 从我的阅读来看，git-repack 似乎是首选，有人可以对此发表评论吗？

我真正想知道的是如何确定depth 和window 的值。我使用 git 提交、推送、拉取和合并，我不知道增量链或对象窗口是什么。

Answer 1

我用不同的值进行了一些测试。这太大了，无法评论 twalbergs 的答案。

我的公司有一个代码库，它已经在 svn、mercurial 和现在的 git 中。它已有 10 年历史，有 21,000 次提交。

在打包之前它是 3.1 GB。重新包装后，它缩小到以下值：
（每次在 3.1GB 文件夹的新克隆上运行重新打包）。

git repack -a -d --depth=50 --window=10 -f
141.584 MB

git repack -a -d --depth=250 --window=1000 -f
110.484 MB

git repack -a -d --depth=500 --window=1000 -f
110.204 MB

他们在我的四核 mac 上分别花费了大约 5、15 和 30 分钟。

---

更新：

我进行了第二次重新打包 (250,1000) 并使用 500 和 1000 重新打包以查看新的 3.1gb 存储库和已经重新打包的 110mb 存储库之间是否有任何区别。

git repack -a -d --depth=250 --window=1000 -f
110.484 MB
git repack -a -d --depth=500 --window=1000 -f
110.212 MB

结论：重新打包 500、1000 生成一个 110.2 MB 的文件，无论它是否已经打包。

更新2：

我进一步好奇，如果在已经重新打包的 repo 上运行具有较低值的重新打包会导致大小增加。

git repack -a -d --depth=500 --window=1000 -f
110.204 MB
git repack -a -d --depth=50 --window=10 -f  
142.056 MB

结论：重新打包导致 repo 大小从 110 MB 膨胀到 ~140 MB

Answer 2

“对象窗口” - 在重新打包 git 时，将每个对象（每个文件的每个版本、每个目录树对象、每个提交消息、每个标签...）与一定数量的其他类似对象进行比较以查找创建最小 delta 的一个 - 粗略地说，可以从该基础对象创建该对象的最小补丁。

“增量链” - 如果要重新创建对象 A，您首先必须检查对象 B 并对其应用增量，但要创建 B，您需要对象 C，这需要 D .. ..

在一定程度上，同时增加depth 和window 可以为您提供更小的包。但是，也有取舍。对于window，较高的设置意味着git repack 将在运行时将每个对象与更多对象进行比较，从而导致git repack 的运行时间（可能显着）更长。但是，一旦生成了包，window 就不会影响进一步的操作（无论如何，在其他 repacks 之外）。另一方面，depth 对git repack 本身的运行时间影响较小（尽管它仍然会对其产生一定的影响），但是您的增量树越深，重建旧对象所需的时间就越长创建文件所需的基础对象序列。这意味着当您引用较旧的提交时，checkout 之类的时间会更长，因此如果您对历史进行大量挖掘，它会对git 的感知效率产生重大影响。而且，由于git 不会仅针对较旧的对象创建增量，因此您有时会发现一个提取速度较慢的最近对象，因为它位于树下的多个级别 - 它不像较旧的对象那样常见，但它确实发生了。

我个人在我的所有存储库中都使用 window=1024 和 depth=256，除了一些非常大的项目（例如 Linux 内核）的克隆。