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.
 
 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.
 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.