服务器上的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 }'分析结果 cut -c53-60 <filename> | grep -v '-' | awk '{ sum += $1 } END { print sum }' 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

在GitHub上查看我的问题。 以下是我们所做的总结：

• 我们已经看到服务器仓库比客户端仓库大得多（> 270次）。
• 我们通过命令git verify-pack -v得到了一些关于pack文件的详细信息（这就是服务器repo更大的原因）（感谢@ max360）。
• 单独的结果文件的大小（类似于包文件本身的大小向我们显示索引中包含更多的对象。
• 我们不知道原因，我们曾经认为GitBlit会自动降低它（它没有'），但是在git gc --prune --agressive ，前12 GB包文件缩小到~110 MB大小。

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

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