遅いGit操作

Question

私はGitの下に置くテストリポジトリを持っています。ほとんどのファイルはかなり小さいですが、非常に多数あり、単にaddやstatusなどのGit操作が完了するまでに数十分かかります。これらをリビジョン管理下に置き、合理的なパフォーマンスを得るための私の選択肢は何ですか？サブモジュールを使用するか、DVCSをクリアする必要がありますか？

Answer 1

addとstatusのようなギット操作では、ファイルシステム内のすべてのファイルを（変更を検出するために）必要とします。本当に膨大な数のファイル（たとえば、数十万または数十万のファイル）を持っているか、どちらかというと遅いファイルシステムを持っていますか？stat

いずれにしても、これが極端に遅いシステムで作業する必要がある場合は、インデックスに "変更されていない"ビットを使用して、Gitにファイルstatを送信しないように指示できます。これをオンにすると、個々のファイルの変更を手に入れるようにgitに手動で指示する必要があります。それらを直接git addに渡すことによって、Gitは何も変わったことを知ることさえできません。 git config core.ignoreStat trueを設定し、次にgit reset --hard HEADのようなものを実行して、これを有効にすることができます。

Answer 2

「非常に大きい」数字は何ですか？通常はgitが厄介なものを見つける小さなファイルの量ではなく、大きなバイナリファイルです。しかし、その量が十分に大きければ、サブモジュールや他の方法でいくつかのリポジトリに分割したいと思っています。 1つのリポジトリに存在する必要がある場合は、たとえばSubversionがよりパフォーマンスに優れていることがわかります。

EDIT：okだから、ここではボトルネックのように思えるNFSマウントを使用するというコメントを追加しました。 this threadの解決方法をご確認ください。特にここではcore.preloadindexが関心の対象です。 the documentationから

：ファイルシステム上の

core.preloadindex

のgit diffのよう

を操作に対する並列インデックス・プリロードを有効にします。これは、Gitの差分とgitのステータスのような操作をスピードアップすることができ、特に NFSのように弱いキャッシュセマンティクスを持っているため、比較的高いIOレイテンシを持っています。これをtrueに設定すると、gitは のファイルシステムデータとのインデックス比較を並列に実行し、 のIOが重複します。

EDIT2：コメントに6百万のファイルが記載されています。私はこれがボトルネックになることを理解することができます - それは確かに非常に大量です。