Git 服务器上的存储库比包含所有分支的本地克隆大得多
Git repository on server is much bigger than local clone with all branches
我们目前面临一个奇怪的情况，一个本地克隆只有 65MB 的存储库在服务器上（GitBlit，但这应该无关紧要）12 GB 的大小。我尝试了不同的想法，这里可能会出什么问题，这是列表：
- 为服务器上的每个分支完成
git ls-tree -r -t -l --full-name HEAD > stats.txt，并收集了该信息。
- 分析结果
cut -c53-60 <filename> | grep -v '-' | awk '{ sum += } 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 倍），这单独解释了包中的差异。下一步应该做什么来找到更多行的原因？统计数据的某些方面是否更有趣？
查看我的 ticket on GitHub 关于这个问题。以下是我们所做工作的总结：
- 我们已经看到服务器 repo 比客户端大得多（> 270 倍）。
- 我们通过命令
git verify-pack -v（感谢@max360）获得了有关打包文件的一些详细信息（这就是服务器回购协议更大的原因）。
- 单独结果文件的大小（类似于包文件本身的大小向我们表明索引中包含的对象更多。
- 我们不知道这是什么原因，我们原以为 GitBlit 会自动减少它（它没有'），但是在
git gc --prune --agressive 之后，前 12 GB打包文件的大小缩小到 ~ 110 MB。
我们不知道是什么问题导致存储库膨胀，但至少我们找到了再次缩小它的方法。
@James Moger 在 GitHub 票证中解释说，在 GitBlit 上执行 GC 是一项实验性功能，因为使用 JGit 而不是 Git binary，GitBlit 完成的 GC 结果可能与上面的 git gc 命令不同。
我们目前面临一个奇怪的情况，一个本地克隆只有 65MB 的存储库在服务器上（GitBlit，但这应该无关紧要）12 GB 的大小。我尝试了不同的想法，这里可能会出什么问题，这是列表：
- 为服务器上的每个分支完成
git ls-tree -r -t -l --full-name HEAD > stats.txt，并收集了该信息。 - 分析结果
cut -c53-60 <filename> | grep -v '-' | awk '{ sum += } 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 倍），这单独解释了包中的差异。下一步应该做什么来找到更多行的原因？统计数据的某些方面是否更有趣？
查看我的 ticket on GitHub 关于这个问题。以下是我们所做工作的总结：
- 我们已经看到服务器 repo 比客户端大得多（> 270 倍）。
- 我们通过命令
git verify-pack -v（感谢@max360）获得了有关打包文件的一些详细信息（这就是服务器回购协议更大的原因）。 - 单独结果文件的大小（类似于包文件本身的大小向我们表明索引中包含的对象更多。
- 我们不知道这是什么原因，我们原以为 GitBlit 会自动减少它（它没有'），但是在
git gc --prune --agressive之后，前 12 GB打包文件的大小缩小到 ~ 110 MB。
我们不知道是什么问题导致存储库膨胀，但至少我们找到了再次缩小它的方法。
@James Moger 在 GitHub 票证中解释说，在 GitBlit 上执行 GC 是一项实验性功能，因为使用 JGit 而不是 Git binary，GitBlit 完成的 GC 结果可能与上面的 git gc 命令不同。