長いローカル履歴が必要ないローカル .git フォルダーのサイズを縮小することをお勧めしますgit gc --aggressive --prune。git repack -a -d --depth=250 --window=250私の読書からは、それgit-repackが好まれているようですが、誰でもこれについてコメントできますか?
私が本当に知りたいのは、depthとの値を決定する方法windowです。私は git を使用してコミット、プッシュ、プル、マージを行っていますが、デルタ チェーンやオブジェクト ウィンドウが何であるかはわかりません。
「オブジェクト ウィンドウ」 - 再パック時にgit各オブジェクト (すべてのファイルのすべてのバージョン、すべてのディレクトリ ツリー オブジェクト、すべてのコミット メッセージ、すべてのタグなど) を特定の数の他の同様のオブジェクトと比較して、最小のデルタを作成するオブジェクトを見つけます。 - 大まかに言えば、そのベース オブジェクトからこのオブジェクトを作成できる最小のパッチです。
「デルタ チェーン」 - オブジェクト A を再作成するために、まずオブジェクト B をチェックアウトしてそれにデルタを適用する必要がありますが、B を作成するにはオブジェクト C が必要であり、これには D が必要です ....
ある程度まで、両方depthを増やして、windowより小さなパックを与えることができます. ただし、トレードオフがあります。の場合window、高い設定は、git repack実行中に各オブジェクトをより多くのオブジェクトと比較することを意味し、結果として の実行時間が (場合によっては大幅に) 長くなりgit repackます。ただし、パックが生成されると、以降の操作には影響しません (とにかくwindow、他の の外部)。一方、それ自体の実行時間への影響は少ないですが (多少の影響はありますが)、デルタ ツリーが深くなるほど、必要な一連のベース オブジェクトから古いオブジェクトを再構築するのに時間がかかります。ファイルを作成します。つまり、次のような場合に時間がかかりますrepackdepthgit repackcheckoutgit古いコミットを参照している場合、履歴を何度も掘り下げる場合に、認識される効率に大きな影響を与える可能性があります。また、 ではgit古いオブジェクトに対してのみデルタが作成されるわけではないため、最近のオブジェクトは抽出が遅いことが時々あります。これは、ツリーの下位レベルにあるためです。古いオブジェクトほど一般的ではありませんが、実際に発生します。
私は個人的に、非常に大きなプロジェクト (Linux カーネルなど) のいくつかのクローンを除いて、すべてのリポジトリでwindow=1024andを使用しています。depth=256