どのくらいの頻度で git-gc を使用する必要がありますか?
マニュアルページには次のように書かれています:
ユーザーは、各リポジトリ内で定期的にこのタスクを実行して、良好なディスク容量の使用率と良好な動作パフォーマンスを維持することをお勧めします。
オブジェクト数を取得して gc の時期かどうかを判断するコマンドはありますか?
それは主に、リポジトリの使用量に依存します。1 人のユーザーが 1 日に 1 回チェックインし、ブランチ/マージ/etc 操作を週に 1 回行う場合、おそらく年に 1 回以上実行する必要はありません。
数十人の開発者が数十のプロジェクトに取り組んでおり、それぞれが 1 日に 2 ~ 3 回チェックインしているため、夜間に実行することをお勧めします。
ただし、必要以上に頻繁に実行しても問題はありません。
私がすべきことは、今すぐ実行してから、1 週間後にディスク使用率を測定し、もう一度実行して、ディスク使用率を再度測定することです。サイズが 5% 低下した場合は、週に 1 回実行します。より多くドロップする場合は、より頻繁に実行してください。ドロップが少ない場合は、実行頻度を減らします。
リポジトリのガベージ コレクションの欠点は、ガベージが収集されることです。コンピューター ユーザーとして誰もが知っているように、現在ゴミと見なされているファイルが、3 日後には非常に価値のあるものになる可能性があります。git が残骸のほとんどを保持しているという事実は、私のベーコンを何度か救いました。ぶら下がっているすべてのコミットを参照することで、誤って缶詰にしていた多くの作業を回復しました。
だから、あなたの個人的なクローンであまりにもきちんとしたフリークにならないでください. その必要はほとんどありません。
OTOH、データの回復性の価値は、主にリモートとして使用されるリポジトリでは疑問です。すべての開発者がプッシュおよび/またはプルする場所。そこでは、GC の実行と再パッキングを頻繁に開始するのが賢明かもしれません。
git の最近のバージョンでは、必要に応じて gc が自動的に実行されるため、何もする必要はありません。man git-gc(1)のオプション セクションを参照してください。
Git-Guiを使用している場合は、いつ心配する必要があるかがわかります。
This repository currently has approximately 1500 loose objects.
次のコマンドは、同様の番号をもたらします。
$ git count-objects
ただし、そのソースから、git-gui はそれ自体で計算を行い、実際にフォルダーで何かをカウントし、おそらく概算をもたらします (それを適切に読み取ること.git/objects
はできません!)。tcl
いずれにせよ、約300 個のゆるいオブジェクトの任意の数に基づいて警告を出すようです。
あなたが眠っているときに毎晩(午後?)実行されるcronジョブにドロップします。
新しい (Git 2.0 Q2 2014) 設定を使用すると、中断することなく実行できますgc.autodetach
。
commit 4c4ac4dおよびcommit 9f673f9 ( Nguyễn Thái Ngọc Duy、別名 pclouds )を参照してください。
gc --auto
時間がかかり、ユーザーを一時的にブロックする可能性があります (ただし、煩わしくはありません)。
それをサポートするシステムでバックグラウンドで実行します。
バックグラウンドでの実行で失われる唯一のものは、印刷物です。しかしgc output
、実際には面白くありません。
変更することでフォアグラウンドに保持できますgc.autodetach
。
ただし、その 2.0 リリース以降、バグがありました。git 2.7 (2015 年第 4 四半期)では、エラー メッセージが失われないようにします。Nguyễn Thái Ngọc Duy ( )によるコミット 329e6e8 (2015 年 9 月 19 日)
を参照してください。( 2015 年 10 月 15 日、コミット 076c827でJunio C Hamanoによってマージされました)pclouds
gitster
gc
: デーモン化されたログを保存しgc --auto
、次回に出力しますコミット 9f673f9 ( :
gc
バック--auto
グラウンドで実行するための構成オプション - 2014-02-08) は、' ' が端末を独占することについての苦情を減らすのに役立ちますgc --auto
が、別の問題を引き起こします。このセットの最新のものは、デーモン化の結果として
stderr
閉じられ、すべての警告が失われます。の最後にあるこの警告は、 " " が繰り返し実行されるcmd_gc()
のを避ける方法をユーザーに伝えるため、特に重要です。stderr が閉じられているため、ユーザーは知りません。当然、 CPU の浪費 について不満を漏らします。gc --auto
gc --auto
Daemonized
gc
が に保存stderr
されるようになりました$GIT_DIR/gc.log
。
以下は、ユーザーが削除するまでgc --auto
実行およびgc.log
印刷されgc.log
ません。
大規模なチェックアウトを行った後、git gc を使用し、新しいオブジェクトがたくさんあります。スペースを節約できます。たとえば、git-svn を使用して大きな SVN プロジェクトをチェックアウトし、git gc を実行すると、通常、多くのスペースを節約できます。
大きなコミットを行うとき、特にリポジトリからより多くのファイルを削除するときに使用します..その後、コミットが高速になります