Question

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

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

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的文件，无论它是否已被打包。

<强> UPDATE2：

如果在已经重新包装的仓库中运行具有较低值的重新包装将导致尺寸增加，我更加好奇。

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 chain” - 当为了重新创建对象A时，首先必须检查对象B并对其应用增量，但是为了创建B，您需要对象C，这需要D .. ..

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

我个人在我的所有回购中使用window=1024和depth=256，除了几个非常大的项目克隆（例如Linux内核）。

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

2 个答案: