gitのrerere機能についてさまざまなことを読んだので、有効にすることを検討しています。しかし、使用中に発生する可能性のある問題について誰も言及していません。私は欠点があると仮定する必要があります。そうしないと、おそらくデフォルトで有効になります。それで、rerereを有効にすることの欠点はありますか?それ以外の場合に発生しないと思われる潜在的な問題は何ですか?
Resolved 'index.html' using previous resolution.
gitのrerere機能についてさまざまなことを読んだので、有効にすることを検討しています。しかし、使用中に発生する可能性のある問題について誰も言及していません。私は欠点があると仮定する必要があります。そうしないと、おそらくデフォルトで有効になります。それで、rerereを有効にすることの欠点はありますか?それ以外の場合に発生しないと思われる潜在的な問題は何ですか?
Resolved 'index.html' using previous resolution.
回答:
マージを誤って行い、それを破棄して、「同じ」マージを再度行うと、再び正しくなくなります。ただし、記録された解像度は忘れることができます。ドキュメントから:
git rerere forget <pathspec>
これにより、rerereがで現在の競合について記録した競合解決がリセットされ
<pathspec>
ます。
特定のパスで使用するように注意してください。記録されたすべての解像度をどこにでも吹き飛ばしたくありません。(明示的に要求するために入力しない限り、forget
引数を指定しないことは、これを回避するために推奨されていませんgit rerere forget .
。)
しかし、そのようにしないと、誤ったマージを履歴に簡単に入れてしまう可能性があります。
rerere
まだマージされていないとしてマークされた競合のあるファイルを残しているので、コミットする前に手動で追加する必要があります(できれば検査/テストした後)。を使用git checkout -m <path>
して、元の競合バージョンをチェックアウトし、必要に応じて解決をやり直すことができます。
JC浜野が彼の記事で言及しているように「Rerereの楽しみ」
- Rerereは、競合した領域を解決するために選択した方法を記憶しています。
- Rerereはまた、セマンティックの変更に適応するために、競合する領域の外側をどのように修正したかを記憶しています。
- Rerereは、以前に解決したブランチとは異なる内容の2つのブランチをマージしていたとしても、以前の解決を再利用できます。
長い間rerereを使ってきた人でも最後のポイントに気付かないことがよくあります。
したがってrerere
、コンテンツが広すぎる場合にアクティブ化すると、最後のポイントのために、マージ解決が驚くべきまたは混乱する可能性があります。
グローバルに有効になっているrerereを持っています。私は本当に問題に気づいていません、そしてそれは通常私の人生を楽にするようです。
バイナリファイルのみを含むコミット(gitk)を選択しました。競合のためにチェリーピックは失敗しました(これは当然のことです)、私はチェリーピックを維持しながら競合を解決しました。後で別のリベースされたブランチでdllが動作しないことに気付いて驚いた-(私は推測する)自動競合解決としてそれらがリベースに持ち込まれていないことを発見しただけだ。したがって、これは、直感に反する(完全に一貫していることは確かですが)動作に遭遇した(rerereが有効になっている)唯一のケースです。
git rerere forget path/to/compiled/bin.dll