服务器上的Git仓库比本地克隆的所有分支要大得多。

Question

我们面临着一个奇怪的情况，一个本地克隆仓库只有65MB，但是在服务器上（GitBlit，但这并不重要）却有12GB大小。我尝试了不同的想法来解决这个问题，以下是列表：

- 对服务器上的每个分支都执行“git ls-tree -r -t -l --full-name HEAD > stats.txt”命令，并收集信息。 - 使用“cut -c53-60 | grep -v '-' | awk '{ sum += $1 } END { print sum }'”分析结果，总结所有提交的文件大小。 - 结果显示大约150MB。

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

我的本地目录“.git/objects/pack”中有一个pack文件，目前大小为17MB（经过GC后，之前为21MB）。服务器上的pack文件目前大小为12GB。

我按照正常方式克隆了该仓库：“git clone https://myserver.mycompancy.com/gitblit/r/projectID/projectID.git”，并得到了本地副本。为确保，我执行了“git fetch --all”命令，但没有变化。

那么我们该如何找出服务器上pack文件更大的原因呢？GitBlit有一个自动GC运行程序，它会打包7天以上未使用的loose对象。

更新：我按建议在本地克隆和服务器上执行了“git verify-pack -v”命令，以下是结果（仅作为统计数据）：

- 结果行数

本地：60,156

服务器：16,456,844

因此，服务器上的pack文件长度大约是本地文件的270倍，这就解释了pack文件大小的差异。接下来应该采取什么步骤找出更多行的原因？统计数据的哪些方面更有趣呢？

- mliebelt

---

git verify-pack -v 会显示对象的大小。 - max630

你说克隆体大小是65MB。你是怎么克隆的？ - James Moger

你尝试在服务器上运行 git gc 了吗？ - Claudio

Answer 1

请看这个关于问题的GitHub上的票据。以下是我们所做的总结：

• 我们发现服务器仓库比客户端仓库大得多（>270倍）。
• 通过命令git verify-pack -v（感谢@max360），我们了解到pack文件的一些细节（这也是服务器仓库比较大的原因）。
• 结果文件的大小（类似于pack文件本身的大小）告诉我们索引中包含了更多的对象。
• 我们不知道原因，本以为GitBlit会自动缩小它，但经过git gc --prune --agressive处理后，之前12GB的pack文件大小被缩小至约110MB。

我们不知道仓库膨胀的原因，但至少我们找到了一种方法来将其缩小。

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

- mliebelt

---

谢谢您的工单！我因为同样的问题省了很多时间。 - wazz