git - 如何使用 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 来提交、推送、 pull 和 merge ，我不知道增量链或对象窗口是什么。

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:

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

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