feat(conflict): detect and resolve inline merge conflict markers#96
Open
barrettruth wants to merge 6 commits intomainfrom
Open
feat(conflict): detect and resolve inline merge conflict markers#96barrettruth wants to merge 6 commits intomainfrom
barrettruth wants to merge 6 commits intomainfrom
Conversation
Problem: when git hits a merge conflict, users stare at raw <<<<<<< markers with broken treesitter and noisy LSP diagnostics. Existing solutions (git-conflict.nvim) use their own highlighting rather than integrating with diffs.nvim's color blending pipeline. Solution: add conflict.lua module that detects <<<<<<</=======/>>>>>>> markers (with diff3 ||||||| support), highlights ours/theirs/base regions with blended DiffsConflict* highlight groups, provides resolution keymaps (doo/dot/dob/don) and navigation (]x/[x), suppresses diagnostics while markers are present, and auto-detaches when all conflicts are resolved. Fires DiffsConflictResolved user event on last resolution.
Problem: lua-language-server reports duplicate @Class definitions for ConflictKeymaps and ConflictConfig (defined in both init.lua and conflict.lua), and inject-field errors for the untyped parser table. Solution: remove duplicate @Class annotations from conflict.lua (init.lua is the canonical source), and annotate the parser's current variable as diffs.ConflictRegion? so LuaLS knows its shape.
Problem: LuaLS reports missing-fields errors because the parser builds ConflictRegion tables incrementally, but the variable is typed as diffs.ConflictRegion? which expects all required fields at construction. Solution: type the work-in-progress variable as table? and cast to diffs.ConflictRegion on insertion into the results array.
Problem: virtual text showed generic "current"/"incoming" labels with no indication of which branch each side came from. Solution: extract the branch name from the marker line itself (e.g. <<<<<<< HEAD, >>>>>>> feature) and display as "HEAD (current)" / "feature (incoming)".
238df23 to
bae86c5
Compare
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
When git hits a merge conflict, users stare at raw
<<<<<<</=======/>>>>>>>markers with broken treesitter and noisy LSP diagnostics. Existing solutions like git-conflict.nvim use their own highlighting rather than integrating with diffs.nvim's color blending pipeline.Solution
Add a
conflict.luamodule that detects inline merge conflict markers and provides a native resolution experience. Supports both standard and diff3 (|||||||) formats.Highlights ours/theirs/base regions with blended
DiffsConflict*highlight groups derived fromDiffAdd/DiffChange/DiffTextbackgrounds, matching the existing color pipeline. Provides resolution keymaps (doo/dot/dob/don) and navigation (]x/[x), all configurable or individually disableable. Suppresses LSP diagnostics while markers are present and re-enables them on resolution. Fires aDiffsConflictResolveduser event when the last conflict in a buffer is resolved.Detection runs on
BufReadPostand re-scans onTextChanged. The entire feature is behindconflict.enabled(defaulttrue) and adds no overhead to buffers without markers.