Git の pull / merge が --no-ff だと自分の Mac と会社の Mac で wada811/dotfiles を更新/同期していると
以下の画像のようにマージコミットが増えていってコミットグラフも分岐してしまいます。
ただ異なる環境で編集しているだけなのに
このように本質的でないコミットが増えていくのは本意ではありません。
git pull --ff-only で実行すれば良い
上の例では確かにそうです。しかし、 Brewfile + Homebrew + Homebrew-caskで Mac の環境構築をする | DevAchieve で書いた
HomeBrew / HomeBrew-cask の更新では
brew upgrade で内部的に git pull が実行されるので、
オプションを付けることができません。
個人的な設定により Non Fast-forward なので マージコミットを作成しようとして
コミットメッセージ入力待ちで処理が止まってしまいます。
HomeBrew / HomeBrew-cask の更新処理はそこそこ時間がかかるので
見張っていなければならないという状況は地味にストレスです。
HomeBrew / HomeBrew-cask をこちらで編集する気がないので --ff で merge したいので
デフォルトの pull の挙動を Fast-Forward only にしてしまいます。
Git の pull を Fast-Forward only にする
git config --global pull.ff onlyIn what cases could `git pull` be harmful? - Stack Overflow
ただし、 Git 2.0 以上から。
ちなみに Git は現在 1.9.3 が最新です。
Git 2.0 は 5月中旬以降にリリース予定らしいです。
つまり、現状では不可能でした。
Git の alias は既存のコマンドを上書きできませんし、
Git の処理自体を書き換えるつもりもないので
おとなしく Git 2.0 がリリースされるのを待ちます。
Git の merge を Fast-Forward にしてしまえば解決しますが、
ブランチのマージの際にブランチが存在したという履歴がなくなってしまうので
こちらのデメリットのほうが大きなってしまうので Fast-Forward にはしません。
参考: 「こわくない Git」というスライドを発表しました - kotas.tech
おまけ
普段 git pull していたけどカレントブランチとは異なるリモートブランチを pull して事故ることもあったりしたので
git fetch を使うようにしようかな。
参考: Git pullを使うべきでない３つの理由 - DQNEO起業日記