rerere: mention caveat about unmatched conflict markers
authorThomas Gummerer <t.gummerer@gmail.com>
Tue, 28 Aug 2018 21:27:43 +0000 (22:27 +0100)
committerJunio C Hamano <gitster@pobox.com>
Wed, 29 Aug 2018 15:54:11 +0000 (08:54 -0700)
4af3220 ("rerere: teach rerere to handle nested conflicts",
2018-08-05) introduced slightly better behaviour if the user commits
conflict markers and then gets another conflict in 'git rerere'.

However this is just a heuristic to punt on such conflicts better, and
doesn't deal with any unmatched conflict markers. Make that clearer
in the documentation.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical/rerere.txt
index e65ba9b0c6b91e40019e16d46ce843d91af580f8..aa22d7ace8930fab0d54adc0e613055ea1aca0f4 100644 (file)
@@ -149,6 +149,10 @@ version, and the sorting the conflict hunks, both for the outer and the
 inner conflict.  This is done recursively, so any number of nested
 conflicts can be handled.
 
+Note that this only works for conflict markers that "cleanly nest".  If
+there are any unmatched conflict markers, rerere will fail to handle
+the conflict and record a conflict resolution.
+
 The only difference is in how the conflict ID is calculated.  For the
 inner conflict, the conflict markers themselves are not stripped out
 before calculating the sha1.