为什么我的Git仓库比Mercurial版本大这么多？

Question

我使用fast-export将Mercurial仓库转换为Git仓库，但是Git仓库非常大：18 GB对比Mercurial的3.4 GB。我的清理步骤都没有帮助。

我的Mercurial仓库由一个占据主导地位的65 MB文件（SQLite格式的Anki闪存卡片）组成，该文件每天更新。它的历史记录已经增长到2.9 GB，在.hg/store/data下。

我希望Git能够更好地压缩历史记录，但是我无法将存储库缩小到18 GB以下！

我尝试了git prune、git gc等方法，但都没有成功。我甚至尝试了将.git文件夹压缩成zip文件，但仍然是18 GB。

我错过了什么吗？

更新：我尝试了Bazaar（bzr），它将我的存储库压缩到仅2.3 GB。不错！

- slattery

---

你尝试过使用 git gc --aggressive 命令吗？ - cdhowie

我确实尝试了git gc --aggressive，但是由于内存错误，在运行一段时间后它就崩溃了。但是到那时，它正在创建的临时包文件已经超过了5 GB… 它看起来并不比我之前运行的git gc要好。 - slattery

我知道你没有选择我的答案，但我仍然认为你应该尝试将sqlite数据库的转储存储起来，而不是存储数据库本身。大多数版本控制系统对看起来像源代码的东西比二进制数据更友好，即使它们实际上可以处理二进制数据。 - Omnifarious

Answer 1

一个原因可能是Mercurial具有非常紧凑的存储格式，即使对于二进制文件也涉及差异。而且，由于使用差异来重新创建版本可能非常耗时，一旦差异+旧原始文件超过完整快照的两倍大小，它将存储完整快照。

个人建议尝试存储SQLite数据库的转储而不是数据库文件本身，并查看效果如何。这可能更有效率。

我不知道git的存储格式是什么。但我猜想它的差异方式与Mercurial的不同。

- Omnifarious

---

Git还执行差分压缩，然后对包执行zlib的处理。 - cdhowie

谢谢提供信息。我只是有点失望，因为我还没有能够顺利地将这个代码库转换到Git上。 - slattery

建议使用 SQLite 转储而不是对数据库本身进行版本控制，我给这个建议点赞。Git（实际上Mercurial也是如此）主要是一个源代码控制系统，而不是用于各种数据的版本控制系统。当然，它可以处理你提供给它的任何东西，只是可能会占用大量空间。 - Tyler

Answer 2

如果git gc失败，请尝试手动运行git repack，然后再运行git gc。

---

我对SVN、Git和Hg的观察：

我一直观察到SVN和Hg仓库比相应的Git仓库小得多。这是因为每个文件（文本或二进制）的每个更改都会添加一个新的完整对象。在SVN中，只添加差异，即使是二进制文件，在SVN中的二进制差异也非常好。

但这就是打包文件的作用，因为它们仅存储类似对象之间的差异（增量），并且甚至进行了压缩。即使进行打包，我观察到Git仓库，根据文件类型和这些文件经历的更改量而定，往往会更大。这是我接受Git的一种妥协，考虑到Git的各种操作有多快，我愿意接受这种妥协。

- manojlds

---

在我比较的代码仓库中，SVN 和 Git 的表现完全相反。在这些仓库中，Git 仓库的大小只有 SVN 仓库的三分之一到五分之一左右。 - Ryan Stewart

@ Ryan Stewart - 就像我所说的，这将取决于文件类型和更改量。具有中等到大型二进制文件且经常更改的存储库在Git中的大小将比在SVN中大，即使已打包。 - manojlds

谢谢@manojlds..看到Git占用了这么多空间，让我感到失望，但我想我必须接受它。目前我会继续在Mercurial中保留这个仓库。也许将来Git能像Mercurial一样高效地存储这个仓库。 - slattery

Answer 3

在从Mercurial迁移的存储库上运行git gc --aggressive对我很有帮助。它将存储库大小从500 MB减少到了150 MB。

- Hugo Leote