On 08/29, Junio C Hamano wrote: > 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. Sorry about that. Yeah Emacs's patch editing mode doing that would explain it. I did a round of proof-reading in my editor, and spotted a typo. Since it was trivial to fix I just edited the patch directly, and Emacs changed the line count. Sorry about that, I'll be more careful about this in the future. > What is curious is that your 2/2 counts the preimage lines > correctly. I only added some text after the '---' line in 2/2, but did not edit the patch directly. Emacs's patch editing mode only seems to change the line numbers of the patch that's being edited, not if anything surrounding that is changed, so the line count stayed the same as what format-patch put in the file in the first place. > In any case, both patches look good. Will apply. Thanks! > Thanks.