Skip to content

feat: add merge-resolver mode for intelligent conflict resolution #6090

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mrubens merged 1 commit into from
Jul 23, 2025
+1,187 −45
Merged

feat: add merge-resolver mode for intelligent conflict resolution #6090

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
142 changes: 142 additions & 0 deletions .roo/rules-merge-resolver/1_workflow.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,142 @@
<merge_resolver_workflow>
<mode_overview>
This mode resolves merge conflicts for a specific pull request by analyzing git history,
commit messages, and code changes to make intelligent resolution decisions. It receives
a PR number (e.g., "#123") and handles the entire conflict resolution process.
</mode_overview>

<initialization_steps>
<step number="1">
<action>Parse PR number from user input</action>
<details>
Extract the PR number from input like "#123" or "PR #123"
Validate that a PR number was provided
</details>
</step>

<step number="2">
<action>Fetch PR information</action>
<tools>
<tool>gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName</tool>
</tools>
<details>
Get PR title and description to understand the intent
Identify the source and target branches
</details>
</step>

<step number="3">
<action>Checkout PR branch and prepare for rebase</action>
<tools>
<tool>gh pr checkout [PR_NUMBER] --force</tool>
<tool>git fetch origin main</tool>
<tool>git rebase origin/main</tool>
</tools>
<details>
Force checkout the PR branch to ensure clean state
Fetch the latest main branch
Attempt to rebase onto main to reveal conflicts
</details>
</step>

<step number="4">
<action>Check for merge conflicts</action>
<tools>
<tool>git status --porcelain</tool>
<tool>git diff --name-only --diff-filter=U</tool>
</tools>
<details>
Identify files with merge conflicts (marked with 'UU')
Create a list of files that need resolution
</details>
</step>
</initialization_steps>

<main_workflow>
<phase name="conflict_analysis">
<description>Analyze each conflicted file to understand the changes</description>
<steps>
<step>Read the conflicted file to identify conflict markers</step>
<step>Extract the conflicting sections between <<<<<<< and >>>>>>></step>
<step>Run git blame on both sides of the conflict</step>
<step>Fetch commit messages and diffs for relevant commits</step>
<step>Analyze the intent behind each change</step>
</steps>
</phase>

<phase name="resolution_strategy">
<description>Determine the best resolution strategy for each conflict</description>
<steps>
<step>Categorize changes by intent (bugfix, feature, refactor, etc.)</step>
<step>Evaluate recency and relevance of changes</step>
<step>Check for structural overlap vs formatting differences</step>
<step>Identify if changes can be combined or if one should override</step>
<step>Consider test updates and related changes</step>
</steps>
</phase>

<phase name="conflict_resolution">
<description>Apply the resolution strategy to resolve conflicts</description>
<steps>
<step>For each conflict, apply the chosen resolution</step>
<step>Ensure proper escaping of conflict markers in diffs</step>
<step>Validate that resolved code is syntactically correct</step>
<step>Stage resolved files with git add</step>
</steps>
</phase>

<phase name="validation">
<description>Verify the resolution and prepare for commit</description>
<steps>
<step>Run git status to confirm all conflicts are resolved</step>
<step>Check for any compilation or syntax errors</step>
<step>Review the final diff to ensure sensible resolutions</step>
<step>Prepare a summary of resolution decisions</step>
</steps>
</phase>
</main_workflow>

<git_commands>
<command name="checkout_pr">
<syntax>gh pr checkout [PR_NUMBER] --force</syntax>
<purpose>Force checkout the PR branch to ensure clean state</purpose>
</command>

<command name="fetch_main">
<syntax>git fetch origin main</syntax>
<purpose>Get the latest main branch from origin</purpose>
</command>

<command name="rebase_main">
<syntax>git rebase origin/main</syntax>
<purpose>Rebase current branch onto main to reveal conflicts</purpose>
</command>

<command name="get_blame_info">
<syntax>git blame -L [start_line],[end_line] [commit_sha] -- [file_path]</syntax>
<purpose>Get commit information for specific lines</purpose>
</command>

<command name="get_commit_details">
<syntax>git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [commit_sha]</syntax>
<purpose>Get commit metadata including message</purpose>
</command>

<command name="get_commit_diff">
<syntax>git show [commit_sha] -- [file_path]</syntax>
<purpose>Get the actual changes made in a commit</purpose>
</command>

<command name="check_merge_status">
<syntax>git ls-files -u</syntax>
<purpose>List unmerged files with stage information</purpose>
</command>
</git_commands>

<completion_criteria>
<criterion>All merge conflicts have been resolved</criterion>
<criterion>Resolved files have been staged</criterion>
<criterion>No syntax errors in resolved code</criterion>
<criterion>Resolution decisions are documented</criterion>
</completion_criteria>
</merge_resolver_workflow>
165 changes: 165 additions & 0 deletions .roo/rules-merge-resolver/2_best_practices.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,165 @@
<merge_resolver_best_practices>
<general_principles>
<principle priority="high">
<name>Intent-Based Resolution</name>
<description>
Always prioritize understanding the intent behind changes rather than
just looking at the code differences. Commit messages, PR descriptions,
and issue references provide crucial context.
</description>
<rationale>
Code changes have purpose - bugfixes should be preserved, features
should be integrated properly, and refactors should maintain consistency.
</rationale>
<example>
<scenario>Conflict between a bugfix and a refactor</scenario>
<good>Apply the bugfix logic within the refactored structure</good>
<bad>Simply choose one side without considering both intents</bad>
</example>
</principle>

<principle priority="high">
<name>Preserve All Valuable Changes</name>
<description>
When possible, combine non-conflicting changes from both sides rather
than discarding one side entirely.
</description>
<rationale>
Both sides of a conflict often contain valuable changes that can coexist
if properly integrated.
</rationale>
</principle>

<principle priority="high">
<name>Escape Conflict Markers</name>
<description>
When using apply_diff or search_and_replace tools, always escape merge
conflict markers with backslashes to prevent parsing errors.
</description>
<example><![CDATA[
Correct: \<<<<<<< HEAD
Wrong: <<<<<<< HEAD
]]></example>
</principle>

<principle priority="medium">
<name>Consider Related Changes</name>
<description>
Look beyond the immediate conflict to understand related changes in
tests, documentation, or dependent code.
</description>
<rationale>
A change might seem isolated but could be part of a larger feature
or fix that spans multiple files.
</rationale>
</principle>
</general_principles>

<resolution_heuristics>
<heuristic category="bugfix_vs_feature">
<rule>Bugfixes generally take precedence over features</rule>
<reasoning>
Bugfixes address existing problems and should be preserved,
while features can be reintegrated around the fix.
</reasoning>
</heuristic>

<heuristic category="recent_vs_old">
<rule>More recent changes are often more relevant</rule>
<reasoning>
Recent changes likely reflect the current understanding of
requirements and may supersede older implementations.
</reasoning>
<exception>
When older changes are bugfixes or security patches that
haven't been addressed in newer code.
</exception>
</heuristic>

<heuristic category="test_updates">
<rule>Changes that include test updates are likely more complete</rule>
<reasoning>
Developers who update tests alongside code changes demonstrate
thoroughness and understanding of the impact.
</reasoning>
</heuristic>

<heuristic category="formatting_vs_logic">
<rule>Logic changes take precedence over formatting changes</rule>
<reasoning>
Formatting can be reapplied, but logic changes represent
functional improvements or fixes.
</reasoning>
</heuristic>
</resolution_heuristics>

<common_pitfalls>
<pitfall>
<description>Blindly choosing one side without analysis</description>
<why_problematic>
You might lose important changes or introduce regressions
</why_problematic>
<correct_approach>
Always analyze both sides using git blame and commit history
</correct_approach>
</pitfall>

<pitfall>
<description>Ignoring the PR description and context</description>
<why_problematic>
The PR description often explains the why behind changes,
which is crucial for proper resolution
</why_problematic>
<correct_approach>
Always fetch and read the PR information before resolving
</correct_approach>
</pitfall>

<pitfall>
<description>Not validating the resolved code</description>
<why_problematic>
Merged code might be syntactically incorrect or introduce
logical errors
</why_problematic>
<correct_approach>
Always check for syntax errors and review the final diff
</correct_approach>
</pitfall>

<pitfall>
<description>Not escaping conflict markers in diffs</description>
<why_problematic>
Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH
or REPLACE sections will be interpreted as actual diff syntax,
causing the apply_diff tool to fail or produce incorrect results
</why_problematic>
<correct_approach>
Always escape conflict markers with a backslash (\) when they
appear in the content you're searching for or replacing.
Example: \<<<<<<< HEAD instead of <<<<<<< HEAD
</correct_approach>
</pitfall>
</common_pitfalls>

<quality_checklist>
<category name="before_resolution">
<item>Fetch PR title and description for context</item>
<item>Identify all files with conflicts</item>
<item>Understand the overall change being merged</item>
</category>

<category name="during_resolution">
<item>Run git blame on conflicting sections</item>
<item>Read commit messages for intent</item>
<item>Consider if changes can be combined</item>
<item>Escape conflict markers in diffs</item>
</category>

<category name="after_resolution">
<item>Verify no conflict markers remain</item>
<item>Check for syntax/compilation errors</item>
<item>Review the complete diff</item>
<item>Document resolution decisions</item>
</category>
</quality_checklist>
</merge_resolver_best_practices>
Loading