jupyter/nbdime

CM6: Several conflict gutter markers placed on the same line

HaudinFlorence opened this issue · 8 comments

When trying to run example6, the following issue has been observed in the merge editor: several conflict gutter markers are produced at the same line (case of line 6), not placed exactly at the same location.

Screenshot from 2023-10-02 15-24-57

I was able to reproduce it, specifically, it looks that there are two copies of the marker in line 5:

image

and the second copy overhangs to line 6.

Well, I am not sure if the issue is in the gutter code or in the chunking algorithm. In this case we get 6 conflict chunks:

image

And two of them have remoteFrom: 4 (so start at line 5, and the second of these leads to overhanging into line 6).

The also seem essentially identical:

First copy Second copy
Screenshot from 2023-10-20 22-54-47 Screenshot from 2023-10-20 22-54-38

Is there any case when duplicate chunks are expected, or is this an error in chunking code?

Is there any case when duplicate chunks are expected, or is this an error in chunking code?

@vidartf is this what you meant by "In certain cases overlapping chunks are not being considered properly overlapping." in issue #677? In that case I think this issue just becomes a duplicate of #677.

There does seem to be a regression here compared to CM5 version. See this example diffing the files in ui-test/data/merge_test1:

CM5:
image

CM6:
image

Notice the extra arrow on the base version on line 5. You can also see the same for CM6 here:

https://github.com/jupyter/nbdime/blob/554c2d34882c77ce48e85586f5db8fce93ed80d1/ui-tests/tests/nbdime-merge-test1.spec.ts-snapshots/merge-test1-take-a-snapshot-at-opening-1-linux.png

Yes, but it is not a bug in CM6 but a bug in how the chunks are calculated as per my comments above.

Of course it still should be fixed, which may be best approached by writing a test case, but it may require more thought/context to understand why the chunking algorithm sometimes leads to duplicate chunks; or we could just add a simple workaround of de-duplicating them without worrying about the algorithm being occasionally wrong.

To clarify, I am using CM5/CM6 as a shorthand for "current stable release" vs "current RC".

(and while there are for sure some bugs in the current stable version's mergeview chunking algorithm, the one I point out above is a new bug in the RC version)