Repository navigation
fix(core): non_overlapping no longer duplicates lines both branches added - #259
Merged
Merged
Conversation
…dded In a diff3 hunk, lines added identically by both branches sit inside the markers on each side. mergeNonOverlapping saw them as two separate edits (ours: a pure insertion at the end of the base; theirs: part of a replacement ending at the same index), found no overlap, and kept both copies. The hunk was classified non_overlapping (80) and auto-applied. The same conflict in zdiff3 resolved correctly, because Git had already taken the common lines out of the hunk. git merge-file --diff3, used by the desktop merge preview and base reconstruction, and the benchmark all produce diff3 markers. - Lines identical at the start and end of ours and theirs are taken out of the merge, as zdiff3 does; the part the base shares is trimmed from the base too, as unchanged context. - A pure insertion placed right after an edit from the other branch that adds some of the same lines is now treated as an overlap: order and deduplication are ambiguous there, so it is left for review. Benchmark (same local corpus, same 26 merge-tree errors on both runs): agreement with the human merge 65.69% -> 66.76% (672 -> 683 of 1023 files), no repo down, coverage unchanged. pnpm bench: within noise.
…oo, note the fix (#259)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Found while checking the blog article on conflict markers. When both branches add the same lines, a conflict written in
diff3style was classifiednon_overlapping(score 80) and auto-applied with those lines twice. The same conflict inzdiff3resolved correctly.Result on
main:timeout: 5000, retries: 5, region, verbose, region, verbose.This matters beyond hand-written markers:
git merge-file --diff3(desktop merge preview, base reconstruction) and the benchmark replay all produce diff3 markers. I reproduced it ongit merge-file -p --diff3output too.Cause
In
mergeNonOverlapping(packages/core/src/diff/shared.ts), ours is a pure insertion ofregion/verboseat base index 2, and theirs is a replacement of[1, 2)that also adds them.editsOverlaptreats an insertion at the other edit'sbaseEndas disjoint (2 < 2is false), so both copies are kept.Fix
zdiff3does. The part the base shares is trimmed from the base too, as unchanged context.x5 y3 R V E1, theirsx3 y5 R V E2),mainproducedR V E2 R V E1; that hunk is now left for review.Verification
pnpm test(core): 1284/1284, including 4 new regression tests (diff3, zdiff3, shared base context, ambiguous insertion).mainvs this branch under identical conditions: agreement with the human merge 65.69% → 66.76% (672 → 683 of 1023 files), no repo down, coverage unchanged. 26 merges failedmerge-treeon both local runs (sandbox blocked blob fetches); the CI gate replays the full corpus.pnpm bench: within noise.