服務器上的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在我的本地克隆和服務器，和這裏的結果（只統計）：結果

• 線
  • 地方：60156
  • 服務器：16456844

因此，服務器上的包文件的時間更長（〜270倍），這隻能解釋包中的差異。下一步應該找到更多線路的原因是什麼？統計的某些方面更有趣？

Answer 1

請參閱我的ticket on GitHub有關該問題。下面是我們所做的一個總結：

• 我們已經看到，服務器回購比客戶端大得多（> 270倍）。
• 我們已經通過命令git verify-pack -v（感謝@ max360）瞭解了pack文件的一些細節（這就是服務器repo更大的原因）。
• 只有結果文件的大小（類似於包文件本身的大小，這表明我們在包含的索引中有更多的對象）
• 我們不知道原因，我們曾想過GitBlit會自動減少它（它沒有），但在git gc --prune --agressive之後，前12 GB的包文件被縮小到〜110 MB的大小。

我們不知道出了什麼問題，導致存儲庫變得臃腫，但至少我們找到了一種方法來再次縮小它。

@James Moger在GitHub票證中解釋說，在GitBlit上做一個GC是一個實驗性功能，而且由於使用JGit而不是Git二進制，所以GitBlit完成的GC結果可能與git gc上面的命令。