Thomas Gummerer <t.gummerer@xxxxxxxxx> writes: > Yeah that makes sense. Maybe something like this? > > (replying to <xmqq4lffk3ez.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> 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. Looks good to me except for the line count on the @@ line. The preimage ought to have 6 (not 7) lines and adding 4 new lines makes it a 10 line postimage. I wonder who miscounted the hunk---it is immediately followed by the signature cut mark "-- \n" and some tools (including Emacs's patch editing mode) are known to misinterpret it as a preimage line that was removed. What is curious is that your 2/2 counts the preimage lines correctly. In any case, both patches look good. Will apply. Thanks.
