git status の結果が遅い場合の対策です。下記の記事の試行錯誤が参考になりました。
git fsck というのを行なっているようです。git fsck は、リポジトリが壊れている場合に壊れている部分を検出できるコマンドだそうです。とりあえず壊れているのか壊れていないかも分からないので、git fsck でチェックします。
1 | git fsck |
待つこと20分。以下のようなメッセージが49行に渡って出力されました。ブラブラブロッブっという翻訳となりますが、詳しい辞書引いてみるとぶら下がりという意味のようです。
1 | dangling blob 1234567890qwertyuiopasdfghjklzxcvbnm1234 |
心配なので調べてみたところ以下の記事が参考になりました。
一般に、dangling オブジェクトが存在しても心配する必要はありません。 どちらかといえば、それらは役に立つものです：何か操作間違いをした時に、 dangling オブジェクトを使用すると元の状態に戻すことができます。 (リベースした後に誤りに気が付いた時、 ある古い dangling の状態に head をリセットすることができます)
リポジトリが破損してる方向性はないようです。次は git gc をやってみます。git gc はリポジトリのいらない所を破棄したり、圧縮してくれるコマンドらしいです。最近物凄い作業をしてコミットしまくってたので、もしかしたらこれを実行すれば動作が軽快になるのでしょうか。
1 | git gc |
実行した所下記のように丁寧なメッセージが15分くらいで出ました。
1 2 3 4 5 6 | Counting objects: 5355, done. Delta compression using up to 4 threads. Compressing objects: 100% (4697/4697), done. Writing objects: 100% (5355/5355), done. Total 5355 (delta 1650), reused 0 (delta 0) Removing duplicate objects: 100% (256/256), done. |
これが多いのか少ないのか分かりませんが、git status は一度実行すると次回は高速になってしまって（キャッシュとか取ってる可能性有り）、うまく検証ができないので、一度何か大型の機能を実装してから改めて git status を実行します。
＊
2時間後作業が一段落したので time git status を実行したら下記の時間で行えました。かなり早く終了しました。ちょっとライブラリを追加したとか、そういう物凄いファイル追加したのが原因か分からりませんが、git gc をすれば改善でいるということが分かりました。
1 2 3 | real 0m0.075s user 0m0.024s sys 0m0.048s |
途中で出てきたコマンドは下記の記事を参考にしました。
コメント