color-words diff of a conflict: `+` prefix misrendered on last line of section

[msuozzo]

Description

With the default "diff" conflict marker style, the %%%%%%% section of a materialized conflict uses + or - line prefixes to indicate repeats/removals. In a color-words diff of a conflicted file, every repeated line renders as a lone inserted + except the last one, which renders as the line removed and re-added in that order meaning the + prefix ends up in the middle of the line. This means the consistency of the + column prefix is broken for that last line.

From what I can tell, this happens because the region around the last copied line has no token that occurs the same number of times on both sides, so unchanged_ranges() has no anchor and reports the line wholly replaced. It is only visible with color on because the no-color layout prints removed and added lines separately.

Steps to Reproduce the Problem

  jj git init repro && cd repro
  printf 'start\nend\n' > file
  jj commit -m A
  printf 'start\n  {\n    one,\n  },\n  {\n    two,\n  },\nend\n' > file
  jj commit -m L
  jj new 'subject("A")'
  printf 'start\n  {\n    three,\n  },\n  {\n    four,\n  },\n  {\n    five,\n  },\nend\n' > file
  jj commit -m M
  jj rebase -s 'subject("M")' -d 'subject("L")'
  jj diff -r 'subject("M")'

(Reproduced on jj 0.43.0 and on main at 6b27ec8)

Expected Behavior

     2    5: +  {
     3    6: +    one,
     4    7: +  },
     5    8: +  {
     6    9: +    two,
     7   10: +  },
         11: +++++++ rmnwmpsu 6216c8d6 "M" (rebased revision)

Actual Behavior

     2    5: +  {
     3    6: +    one,
     4    7: +  },
     5    8: +  {
     6    9: +    two,
     7   10:   },+  },        <-- red "  }," then green "+  },"
         11: +++++++ rmnwmpsu 6216c8d6 "M" (rebased revision)

Specifications

• Platform: macOS
• Version: 0.43.0 and HEAD

[yuja]

From what I can tell, this happens because the region around the last copied line has no token that occurs the same number of times on both sides

That's probably it. There's no clue to prioritize the subsequent } over the other }s in the same hunk.
(EDIT: FWIW, git falls back to Myers diff in that case, but jj doesn't.)

The current materialized conflict diffs aren't ideal. We should find a better presentation fformat. diff.color-words.conflict=pair is an option, but its output can be overly verbose.

[yuja]

git falls back to Myers diff in that case, but jj doesn't.

If we added a fallback, the output would look like:

@@ -1,8 +1,22 @@
 start
+<<<<<<< conflict 1 of 1
+%%%%%%% diff from: wkqvrqtp 3e7f3773 "A" (parents of rebased revision)
+\\\\\\\        to: xpzxklyq a6f721e4 "L" (rebase destination)
++  {
++    one,
++  },
++  {
++    two,
++  },
++++++++ stuuyrnx fb2b6811 "M" (rebased revision)
   {
-    one,
+    three,
   },
   {
-    two,
+    four,
   },
+  {
+    five,
+  },
+>>>>>>> conflict 1 of 1 ends
 end

This is because the },\n{ \n sequence can now contribute to the matches.

(I tested with the Python difflib-like algorithm because it's a simple divide-and-conquer algorithm.)