服务器上的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在我的本地克隆和服务器上按照建议完成了命令,这里是结果(仅作为统计信息):

因此,服务器上的包文件的幅度(~270倍)更长,这就解释了包中的差异.下一步要找到更多线路的原因应该是什么？统计的某些方面更有趣吗？

Answer 1

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

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

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

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