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 }'すべてのコミットのすべてのファイル サイズをまとめて結果を分析しました。
  • その結果、〜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

そのため、サーバー上のパック ファイルは 1 倍 (~ 270 倍) 長く、これだけでパックの違いを説明できます。さらに多くの行がある理由を見つけるための次のステップは何ですか? 統計のいくつかの側面は、より興味深いものですか?

4

1 に答える 1

2

この問題については、GitHub で私のチケットを参照してください。これが私たちが行ったことの要約です：

  • サーバー リポジトリはクライアント リポジトリよりもはるかに大きいことがわかりました (> 270 倍)。
  • git verify-pack -vコマンド(@max360 に感謝) によって、パック ファイル (サーバー リポジトリがはるかに大きい理由) に関する詳細を取得しました。
  • 結果ファイルだけのサイズ (パック ファイル自体のサイズと同様) は、含まれているインデックスにはるかに多くのオブジェクトがあることを示しています。
  • その理由はわかりませんが、GitBlit が自動的にサイズを縮小すると考えていましたが (そうではありませんでした)、git gc --prune --agressive以前の 12 GB のパック ファイルは 110 MB まで縮小されました。

何が原因でリポジトリが肥大化したのかはわかりませんが、少なくとも再び縮小する方法は見つかりました。

@James Moger は GitHub チケットで、GitBlit で GC を実行することは実験的な機能であり、Git バイナリの代わりに JGit が使用されるため、GitBlit によって実行される GC の結果はgit gc上記のコマンドによるものとは異なる可能性があると説明しました。

于 2016-01-18T13:54:04.143 に答える