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 <gits...@pobox.com> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- > That's fine. I'd rather keep it but perhaps add a reminder to tell > readers that it works only when the merging of contents that already > records with nested conflict markers happen to "cleanly nest". Yeah that makes sense. Maybe something like this? (replying to <xmqq4lffk3ez....@gitster-ct.c.googlers.com> here to keep the patches in one thread) Documentation/technical/rerere.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/technical/rerere.txt b/Documentation/technical/rerere.txt index e65ba9b0c6..8fefe51b00 100644 --- a/Documentation/technical/rerere.txt +++ b/Documentation/technical/rerere.txt @@ -149,7 +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. -- 2.18.0.1088.ge017bf2cd1
