服务器上的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得到了一些关于包文件的详细信息（这就是服务器repo更大的原因）（感谢@ max360）。
• 仅结果文件的大小（类似于包文件本身的大小，向我们显示索引中包含更多对象。
• 我们不知道原因，我们原以为GitBlit会自动减少它（它没有＆＃39;），但在git gc --prune --agressive之后，前12 GB包文件是缩小到~110 MB大小。

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

@James Moger在GitHub票证中解释说，在GitBlit上执行GC是一个实验性功能，并且因为使用JGit而不是Git二进制文件，GitBlit完成的GC的结果可能与{{{ 1}}以上命令。