如何使用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来提交,推送,拉取和合并,我不知道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我的所有repos除了几个非常大的项目克隆(例如Linux内核).