git
ストレージが大きくなりすぎないようにするには、git gc
ストアの上で実行する必要があります。しかし、ここにはいくつかの欠点があります。特にメモリを大量に消費します。代替ソリューションは、リポジトリを複製し、元のコピーをレプリカに置き換えるようです。 (これらのストレージはサーバー上でホストされているため、ここには作業コピーはありません。)これにより、I / Oが増えますが、RAMの使用量が少なくなります。
私はこれが同じ効果を持っていないかもしれないと思いますgit gc
が、どうなるかはよくわかりません。質問は次のとおりです。git gc
ベアリポジトリで実行するものと実行し、git clone
リポジトリを削除してレプリカに置き換えることの違いは何ですか?
答え1
多くの違いがあります。
まず、削除と複製のために、リポジトリのコピーが一部のリモートコピーと完全に同期してよりよく圧縮されていますが、同等のリポジトリを新しいレプリカとして作成できると仮定する必要があります。ストレージを同期する必要がなく、ローカルコピーに保持したい変更や分岐がある可能性があるため、これはほとんど発生しません(ネイキッドであっても)。削除後に複製すると、このデータはすべて失われますが、git gc
a。
第二に、サーバーが本質的にレプリカのデルタが良い良いパッケージを生成すると仮定することはできません。ほとんどのGitサーバーは、より良い設定を使用して定期的にデータをパッケージ化するのに時間を費やしますが、オブジェクトを動的にパッケージ化する必要がある要求を処理します。これらの設定では、複数のパッケージと複数のプッシュデータのデータを組み合わせる必要があるため、データをより迅速に生成できますが、パッケージングの効率は低下します。したがって、自分で定期的に再梱包すると、より良い結果が得られ、時には劇的に現れることがあります。
第三に、git gc
中断することなく内部で行うことができますが、複製と交換はUnixでアトミックに行うことはできません(シンボリックリンクを使用しない限り)。 git gc
必要に応じてこれを自動的に実行することもできますが、複製と交換はできません。
第四に、誤ったプッシュやその他のエラーから回復するために参照ログを使用する機能に依存している場合は、複製および交換時にgit gc
。
第五に、ネットワーク接続によっては、git gc
新しいコピーを複製するよりも単に実行する方が速いかもしれません。 2番目のポイントで述べた理由により、リポジトリがリモートでパッケージ化されている方法によっては、複製して交換したいよりも多くのデータを転送する可能性があります。
通常、再パッケージする代わりに、複製と交換を使用する人はいません。実際、非常に大きなリポジトリを持つ人々は、より良いパフォーマンスのために常に再複製するのではなく、自動的にインポートして先制的にパッケージ化する傾向があります。