19

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

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

4

2 回答 2

24

我用不同的值进行了一些测试。这太大了，无法评论 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

于 2014-01-07T18:27:57.380 回答
16

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

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

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

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

于 2013-02-12T21:46:38.727 回答