ご存知のように、定期的に実行git gc
してオブジェクトを。の下にパックできます.git/objects
。
ただし、リモートの中央Gitリポジトリ(ベアまたはそうでない場合)の場合、多くのプッシュの後、myproj.git/objects
;の下に多くのファイルがあります。各コミットはそこに新しいファイルを作成するようです。
どうすればその数のファイルをパックできますか?(つまり、ローカルのクローンリポジトリではなく、リモートの中央のベアリポジトリにあるものを意味します。)
ご存知のように、定期的に実行git gc
してオブジェクトを。の下にパックできます.git/objects
。
ただし、リモートの中央Gitリポジトリ(ベアまたはそうでない場合)の場合、多くのプッシュの後、myproj.git/objects
;の下に多くのファイルがあります。各コミットはそこに新しいファイルを作成するようです。
どうすればその数のファイルをパックできますか?(つまり、ローカルのクローンリポジトリではなく、リモートの中央のベアリポジトリにあるものを意味します。)
リモート リポジトリは、コミット後に必要に応じて gc を実行するように構成する必要があります。gc.auto
ingit-gc
およびgit-config
man ページのドキュメントを参照してください。
ただし、リモート リポジトリには、ダングリング (到達不能) コミットがほとんどないため、それほど多くのガベージ コレクションは必要ありません。これらは通常、ブランチの削除やリベースなどの結果であり、通常はローカル リポジトリでのみ発生します。
そのため、gc は、実際のゴミを削除するのではなく、ストレージ スペースを節約するための再パックに必要です。gc.auto
変数はこれを処理するのに十分です。
何度もプッシュした後、下に多くのファイルがあります
myproj.git/objects
git 2.11+ (2016 年第 4 四半期) と pre-receive フックではそれほど多くはありません。そのシナリオでは、をまったく
トリガーする必要はありません。git gc
commit 62fe0eb、commit e34c2e0、commit 722ff7f、commit 2564d99、commit 526f108 (03 Oct 2016) by Jeff King ( peff
)を参照してください。
( 2016 年 10 月 17 日のcommit 25ab004でJunio C Hamanoによってマージされました)gitster
receive-pack
: pre-receive が受け入れるまでオブジェクトを隔離します「git push」の受信側が受信した履歴を検査し、プッシュを拒否することを決定するには、送信側から送信されたオブジェクトをフックと接続チェックのメカニズムで利用できるようにする必要があり、これが行われました。従来、受信リポジトリにオブジェクトを格納し、"
git gc
" で期限切れにすることによって行われていました。代わりに、新しく受け取ったオブジェクトを一時領域に保存し、チェックを受け入れるかどうかを決定している間だけ代替オブジェクト ストア メカニズムを再利用して使用できるようにし、決定したら、それらをリポジトリに移行するか、すぐに削除します。 .
その一時領域は、新しい環境変数によって設定されますGIT_QUARANTINE_ENVIRONMENT
。
そうすれば、(大きな) プッシュがフックによって拒否された場合、それらの大きなオブジェクトは、クリーンアップをpre-receive
待つために 90 日間放置されることはありません。git gc
この質問は、ガベージ コレクションを実行する頻度を明らかにするはずです。
最も簡単なオプションは、Windows でスケジュールされたタスクを使用するか、Unix で cron ジョブを使用してgit gc
定期的に実行することです。これなら、考える必要もありません。