Skip to content

Commit aa0e6d3

Browse files
daniel-lxsdaniel-lxs
authored
feat: add merge-resolver mode for intelligent conflict resolution (RooCodeInc#6090)
1 parent 0cb76d9 commit aa0e6d3

File tree

11 files changed

+1187
-45
lines changed

11 files changed

+1187
-45
lines changed

‎.roo/rules-merge-resolver/1_workflow.xml‎

Lines changed: 142 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,142 @@
1+
<merge_resolver_workflow>
2+
<mode_overview>
3+
This mode resolves merge conflicts for a specific pull request by analyzing git history,
4+
commit messages, and code changes to make intelligent resolution decisions. It receives
5+
a PR number (e.g., "#123") and handles the entire conflict resolution process.
6+
</mode_overview>
7+
8+
<initialization_steps>
9+
<step number="1">
10+
<action>Parse PR number from user input</action>
11+
<details>
12+
Extract the PR number from input like "#123" or "PR #123"
13+
Validate that a PR number was provided
14+
</details>
15+
</step>
16+
17+
<step number="2">
18+
<action>Fetch PR information</action>
19+
<tools>
20+
<tool>gh pr view [PR_NUMBER] --json title,body,headRefName,baseRefName</tool>
21+
</tools>
22+
<details>
23+
Get PR title and description to understand the intent
24+
Identify the source and target branches
25+
</details>
26+
</step>
27+
28+
<step number="3">
29+
<action>Checkout PR branch and prepare for rebase</action>
30+
<tools>
31+
<tool>gh pr checkout [PR_NUMBER] --force</tool>
32+
<tool>git fetch origin main</tool>
33+
<tool>git rebase origin/main</tool>
34+
</tools>
35+
<details>
36+
Force checkout the PR branch to ensure clean state
37+
Fetch the latest main branch
38+
Attempt to rebase onto main to reveal conflicts
39+
</details>
40+
</step>
41+
42+
<step number="4">
43+
<action>Check for merge conflicts</action>
44+
<tools>
45+
<tool>git status --porcelain</tool>
46+
<tool>git diff --name-only --diff-filter=U</tool>
47+
</tools>
48+
<details>
49+
Identify files with merge conflicts (marked with 'UU')
50+
Create a list of files that need resolution
51+
</details>
52+
</step>
53+
</initialization_steps>
54+
55+
<main_workflow>
56+
<phase name="conflict_analysis">
57+
<description>Analyze each conflicted file to understand the changes</description>
58+
<steps>
59+
<step>Read the conflicted file to identify conflict markers</step>
60+
<step>Extract the conflicting sections between <<<<<<< and >>>>>>></step>
61+
<step>Run git blame on both sides of the conflict</step>
62+
<step>Fetch commit messages and diffs for relevant commits</step>
63+
<step>Analyze the intent behind each change</step>
64+
</steps>
65+
</phase>
66+
67+
<phase name="resolution_strategy">
68+
<description>Determine the best resolution strategy for each conflict</description>
69+
<steps>
70+
<step>Categorize changes by intent (bugfix, feature, refactor, etc.)</step>
71+
<step>Evaluate recency and relevance of changes</step>
72+
<step>Check for structural overlap vs formatting differences</step>
73+
<step>Identify if changes can be combined or if one should override</step>
74+
<step>Consider test updates and related changes</step>
75+
</steps>
76+
</phase>
77+
78+
<phase name="conflict_resolution">
79+
<description>Apply the resolution strategy to resolve conflicts</description>
80+
<steps>
81+
<step>For each conflict, apply the chosen resolution</step>
82+
<step>Ensure proper escaping of conflict markers in diffs</step>
83+
<step>Validate that resolved code is syntactically correct</step>
84+
<step>Stage resolved files with git add</step>
85+
</steps>
86+
</phase>
87+
88+
<phase name="validation">
89+
<description>Verify the resolution and prepare for commit</description>
90+
<steps>
91+
<step>Run git status to confirm all conflicts are resolved</step>
92+
<step>Check for any compilation or syntax errors</step>
93+
<step>Review the final diff to ensure sensible resolutions</step>
94+
<step>Prepare a summary of resolution decisions</step>
95+
</steps>
96+
</phase>
97+
</main_workflow>
98+
99+
<git_commands>
100+
<command name="checkout_pr">
101+
<syntax>gh pr checkout [PR_NUMBER] --force</syntax>
102+
<purpose>Force checkout the PR branch to ensure clean state</purpose>
103+
</command>
104+
105+
<command name="fetch_main">
106+
<syntax>git fetch origin main</syntax>
107+
<purpose>Get the latest main branch from origin</purpose>
108+
</command>
109+
110+
<command name="rebase_main">
111+
<syntax>git rebase origin/main</syntax>
112+
<purpose>Rebase current branch onto main to reveal conflicts</purpose>
113+
</command>
114+
115+
<command name="get_blame_info">
116+
<syntax>git blame -L [start_line],[end_line] [commit_sha] -- [file_path]</syntax>
117+
<purpose>Get commit information for specific lines</purpose>
118+
</command>
119+
120+
<command name="get_commit_details">
121+
<syntax>git show --format="%H%n%an%n%ae%n%ad%n%s%n%b" --no-patch [commit_sha]</syntax>
122+
<purpose>Get commit metadata including message</purpose>
123+
</command>
124+
125+
<command name="get_commit_diff">
126+
<syntax>git show [commit_sha] -- [file_path]</syntax>
127+
<purpose>Get the actual changes made in a commit</purpose>
128+
</command>
129+
130+
<command name="check_merge_status">
131+
<syntax>git ls-files -u</syntax>
132+
<purpose>List unmerged files with stage information</purpose>
133+
</command>
134+
</git_commands>
135+
136+
<completion_criteria>
137+
<criterion>All merge conflicts have been resolved</criterion>
138+
<criterion>Resolved files have been staged</criterion>
139+
<criterion>No syntax errors in resolved code</criterion>
140+
<criterion>Resolution decisions are documented</criterion>
141+
</completion_criteria>
142+
</merge_resolver_workflow>

‎.roo/rules-merge-resolver/2_best_practices.xml‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
<merge_resolver_best_practices>
2+
<general_principles>
3+
<principle priority="high">
4+
<name>Intent-Based Resolution</name>
5+
<description>
6+
Always prioritize understanding the intent behind changes rather than
7+
just looking at the code differences. Commit messages, PR descriptions,
8+
and issue references provide crucial context.
9+
</description>
10+
<rationale>
11+
Code changes have purpose - bugfixes should be preserved, features
12+
should be integrated properly, and refactors should maintain consistency.
13+
</rationale>
14+
<example>
15+
<scenario>Conflict between a bugfix and a refactor</scenario>
16+
<good>Apply the bugfix logic within the refactored structure</good>
17+
<bad>Simply choose one side without considering both intents</bad>
18+
</example>
19+
</principle>
20+
21+
<principle priority="high">
22+
<name>Preserve All Valuable Changes</name>
23+
<description>
24+
When possible, combine non-conflicting changes from both sides rather
25+
than discarding one side entirely.
26+
</description>
27+
<rationale>
28+
Both sides of a conflict often contain valuable changes that can coexist
29+
if properly integrated.
30+
</rationale>
31+
</principle>
32+
33+
<principle priority="high">
34+
<name>Escape Conflict Markers</name>
35+
<description>
36+
When using apply_diff or search_and_replace tools, always escape merge
37+
conflict markers with backslashes to prevent parsing errors.
38+
</description>
39+
<example><![CDATA[
40+
Correct: \<<<<<<< HEAD
41+
Wrong: <<<<<<< HEAD
42+
]]></example>
43+
</principle>
44+
45+
<principle priority="medium">
46+
<name>Consider Related Changes</name>
47+
<description>
48+
Look beyond the immediate conflict to understand related changes in
49+
tests, documentation, or dependent code.
50+
</description>
51+
<rationale>
52+
A change might seem isolated but could be part of a larger feature
53+
or fix that spans multiple files.
54+
</rationale>
55+
</principle>
56+
</general_principles>
57+
58+
<resolution_heuristics>
59+
<heuristic category="bugfix_vs_feature">
60+
<rule>Bugfixes generally take precedence over features</rule>
61+
<reasoning>
62+
Bugfixes address existing problems and should be preserved,
63+
while features can be reintegrated around the fix.
64+
</reasoning>
65+
</heuristic>
66+
67+
<heuristic category="recent_vs_old">
68+
<rule>More recent changes are often more relevant</rule>
69+
<reasoning>
70+
Recent changes likely reflect the current understanding of
71+
requirements and may supersede older implementations.
72+
</reasoning>
73+
<exception>
74+
When older changes are bugfixes or security patches that
75+
haven't been addressed in newer code.
76+
</exception>
77+
</heuristic>
78+
79+
<heuristic category="test_updates">
80+
<rule>Changes that include test updates are likely more complete</rule>
81+
<reasoning>
82+
Developers who update tests alongside code changes demonstrate
83+
thoroughness and understanding of the impact.
84+
</reasoning>
85+
</heuristic>
86+
87+
<heuristic category="formatting_vs_logic">
88+
<rule>Logic changes take precedence over formatting changes</rule>
89+
<reasoning>
90+
Formatting can be reapplied, but logic changes represent
91+
functional improvements or fixes.
92+
</reasoning>
93+
</heuristic>
94+
</resolution_heuristics>
95+
96+
<common_pitfalls>
97+
<pitfall>
98+
<description>Blindly choosing one side without analysis</description>
99+
<why_problematic>
100+
You might lose important changes or introduce regressions
101+
</why_problematic>
102+
<correct_approach>
103+
Always analyze both sides using git blame and commit history
104+
</correct_approach>
105+
</pitfall>
106+
107+
<pitfall>
108+
<description>Ignoring the PR description and context</description>
109+
<why_problematic>
110+
The PR description often explains the why behind changes,
111+
which is crucial for proper resolution
112+
</why_problematic>
113+
<correct_approach>
114+
Always fetch and read the PR information before resolving
115+
</correct_approach>
116+
</pitfall>
117+
118+
<pitfall>
119+
<description>Not validating the resolved code</description>
120+
<why_problematic>
121+
Merged code might be syntactically incorrect or introduce
122+
logical errors
123+
</why_problematic>
124+
<correct_approach>
125+
Always check for syntax errors and review the final diff
126+
</correct_approach>
127+
</pitfall>
128+
129+
<pitfall>
130+
<description>Not escaping conflict markers in diffs</description>
131+
<why_problematic>
132+
Unescaped conflict markers (<<<<<<, =======, >>>>>>) in SEARCH
133+
or REPLACE sections will be interpreted as actual diff syntax,
134+
causing the apply_diff tool to fail or produce incorrect results
135+
</why_problematic>
136+
<correct_approach>
137+
Always escape conflict markers with a backslash (\) when they
138+
appear in the content you're searching for or replacing.
139+
Example: \<<<<<<< HEAD instead of <<<<<<< HEAD
140+
</correct_approach>
141+
</pitfall>
142+
</common_pitfalls>
143+
144+
<quality_checklist>
145+
<category name="before_resolution">
146+
<item>Fetch PR title and description for context</item>
147+
<item>Identify all files with conflicts</item>
148+
<item>Understand the overall change being merged</item>
149+
</category>
150+
151+
<category name="during_resolution">
152+
<item>Run git blame on conflicting sections</item>
153+
<item>Read commit messages for intent</item>
154+
<item>Consider if changes can be combined</item>
155+
<item>Escape conflict markers in diffs</item>
156+
</category>
157+
158+
<category name="after_resolution">
159+
<item>Verify no conflict markers remain</item>
160+
<item>Check for syntax/compilation errors</item>
161+
<item>Review the complete diff</item>
162+
<item>Document resolution decisions</item>
163+
</category>
164+
</quality_checklist>
165+
</merge_resolver_best_practices>

0 commit comments

Comments
 (0)