7

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

  • git ls-tree -r -t -l --full-name HEAD > stats.txt为服务器上的每个分支完成，并收集该信息。
  • cut -c53-60 <filename> | grep -v '-' | awk '{ sum += $1 } END { print sum }'用do 总结所有提交的所有文件大小来分析结果。
  • 结果我们得到了 ~ 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 倍），这仅说明了包中的差异。下一步应该如何找到更多行的原因？统计数据的某些方面是否更有趣？

4

1 回答 1

2

请参阅我在 GitHub 上关于该问题的票证。以下是我们所做的总结：

  • 我们已经看到服务器存储库比客户端存储库大得多（> 270 倍）。
  • git verify-pack -v我们通过命令（感谢@max360）获得了有关包文件的一些详细信息（这就是服务器存储库大得多的原因）。
  • 仅从结果文件的大小（类似于包文件本身的大小）就可以看出索引中包含的对象要多得多。
  • 我们不知道其中的原因，我们曾认为 GitBlit 会自动减少它（它没有），但是在 a 之后git gc --prune --agressive，之前的 12 GB 包文件的大小缩小到了 ~ 110 MB。

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

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

于 2016-01-18T13:54:04.143 回答