服务器上的 Git 存储库比所有分支的本地克隆大得多

Question

我们目前面临一个奇怪的情况，一个本地克隆只有 65MB 的存储库在服务器上(GitBlit，但这应该无关紧要)大小为 12 GB。我尝试了不同的想法，这里可能会出错，这是列表:

• 为服务器上的每个分支完成 git ls-tree -r -t -l --full-name HEAD > stats.txt，并收集该信息。
• 使用 cut -c53-60 <filename> | grep -v '-' | awk '{ sum += $1 } END { print sum }' 分析结果并总结所有提交的所有文件大小。
• 结果我们得到了 ~ 150 MB

所以我们没有发现任何包含大文件的提交。

我的本​​地目录 .git/objects/pack 有一个包文件，当前大小为 17MB(在 GC 之后，之前是 21MB)。服务器上的包文件目前大小为 12 GB。

我以正常方式克隆了存储库:git clone https://myserver.mycompancy.com/gitblit/r/projectID/projectID.git 并获得了本地副本。可以肯定的是，我已经完成了 git fetch --all 而没有改变。

那么我们如何才能找到服务器上的包文件大得多的原因呢？ GitBlit 有一个自动运行的 GC，它将打包超过 7 天的松散对象。

---

更新:我已经按照建议在我的本地克隆和服务器上执行命令 git verify-pack -v，结果如下(仅作为统计数据):

• 结果行
  • 本地:60,156
  • 服务器:16,456,844

因此服务器上的包文件长了一个数量级(约 270 倍)，这单独解释了包中的差异。下一步应该做什么来找到更多行的原因？统计数据的某些方面是否更有趣？

Answer 1

查看我的 ticket on GitHub关于这个问题。以下是我们所做工作的总结:

• 我们已经看到服务器存储库比客户端存储库大得多(> 270 倍)。
• 我们通过命令git verify-pack -v(感谢@max360)获得了关于包文件的一些细节(这就是为什么服务器仓库更大的原因)。<
• 单独结果文件的大小(类似于打包文件本身的大小)向我们表明索引中包含的对象要多得多。
• 我们不知道其中的原因，我们原以为 GitBlit 会自动减少它(它没有')，但是在 git gc --prune --agressive 之后，前 12 GB 的打包文件大小缩小到约 110 MB。

我们不知道出了什么问题导致存储库膨胀，但至少我们找到了一种再次缩小它的方法。

@James Moger 在 GitHub 票证中解释说，在 GitBlit 上执行 GC 是一项实验性功能，并且由于使用 JGit 而不是 Git 二进制文件，因此 GitBlit 执行的 GC 结果可能与 git gc 上面的命令。