90

NFS 上にある Linux マシンに 10 GB のリポジトリがあります。初回git statusは36分、2回目以降git statusは8分。Git はファイルのキャッシュを OS に依存しているようです。、のような最初のgitコマンドだけが、レポ全体をパック/再パックすることを含み、巨大なレポには非常に長い時間がかかります。このような大規模なリポジトリで使用したことがあるかどうかはわかりませんが、この問題に遭遇した人はいますか?commitstatusgit status

git gc、を試しましgit cleanたgit repackが、所要時間はまだ/ほとんど同じです。

サブモジュールや、リポジトリをより小さなものに分割するなどの他の概念は役立ちますか? もしそうなら、より大きなレポを分割するのに最適なのはどれですか。大規模なレポで git コマンドにかかる時間を改善する他の方法はありますか?

4

11 に答える 11

48

より正確に言うと、git はシステム コールの効率に依存するため、クライアントの「属性キャッシュ タイムアウト」</a>lstat(2)を微調整することでうまくいくかもしれません。

for のマニュアルgit-update-index— 基本的には for の手動モード— では、git-statusフラグを使用し--assume-unchangedて通常の動作を抑制し、変更したパスを手動で更新することで、これを軽減する方法について説明しています。ファイルを保存するたびにこのフラグを設定解除するようにエディタをプログラムすることもできます。

あなたが示唆するように、代替手段はチェックアウトのサイズを小さくすることです（パックファイルのサイズは実際にはここでは関係ありません）。オプションは、スパース チェックアウト、サブモジュール、または Google のリポジトリツールです。

( NFS での Gitの使用に関するメーリング リスト スレッドがありますが、多くの質問には答えていません。)

于 2011-02-14T17:27:46.927 に答える
39

NFS で共有されている大規模なプロジェクトでも、この問題が発生しています。

git commit と git status の両方に指定できるフラグ-unoを見つけるのに時間がかかりました。

このフラグが行うことは、追跡されていないファイルの検索を無効にすることです。これにより、nfs 操作の数が大幅に削減されます。その理由は、git が追跡されていないファイルを発見するために、すべてのサブディレクトリを調べる必要があるためです。git が追跡されていないファイルを検索しないようにすることで、これらの NFS 操作をすべて排除できます。

これを core.preloadindex フラグと組み合わせると、NFS でも適切なパフォーマンスを得ることができます。

于 2012-05-30T20:48:24.063 に答える
22

git リポジトリでサブモジュールを頻繁に使用する場合は、.git ディレクトリの構成ファイルを編集し、ignore = dirty特に大きい/重いサブモジュールを設定することで、git ステータスのパフォーマンスを大幅に高速化できます。例えば：

[submodule "mysubmodule"]
url = ssh://mysubmoduleURL
ignore = dirty

忘れている可能性のあるサブモジュールのいずれかにステージングされていない変更があるというリマインダーの便利さは失われますが、サブモジュールがメインリポジトリと同期していないときに知るという主な便利さは引き続き保持されます. さらに、作業ディレクトリをサブモジュール自体に変更し、通常どおりその中で git status を使用して詳細情報を表示することもできます。「汚い」の意味の詳細については、この質問を参照してください。

于 2012-08-24T14:40:27.223 に答える
5

git config --global core.preloadIndex true

私のために仕事をしました。こちらの公式ドキュメントを確認してください。

于 2018-01-23T13:20:40.697 に答える