Fixes AI Resolve mode for conflicts without an active operation#5489
Conversation
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
Fixes AI conflict resolution in the Commit Graph WIP details “Resolve” flow when conflicts exist without an in-progress git operation (e.g., stash pop/apply conflicts, pull with autostash re-apply conflicts, or after git merge --quit). This aligns the RPC handlers with the entry point’s operation-agnostic conflict gating and allows conflict-tools to run without optional ref enrichment.
Changes:
- Removed the hard requirement for a paused operation in
resolveConflictsandreresolveFile, deriving optionalResolutionRefsvia a newgetResolutionRefs()helper. - Removed the apply-time paused-operation stale guard and relied on the existing per-file
listUnmergedPathsguard to prevent applying stale resolutions. - Added a changelog entry documenting the fix for op-less conflict scenarios.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/webviews/plus/graph/graphWebview.ts |
Makes AI resolve/reresolve/apply work when conflicts exist without paused op state by making refs optional and adjusting staleness guarding. |
CHANGELOG.md |
Documents the user-facing fix for AI Resolve mode in op-less conflict cases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
🟢 Conflict resolved with 100% confidence
Comment Resolution details🟢
|
ianhattendorf
force-pushed
the
conflict-error-after-pull
branch
from
efcca26 to
2a2d25c
Compare
Conflicts can exist without a paused git operation — stash pop/apply, pull with autostash where the re-apply conflicts, or merge --quit — but the graph's resolveConflicts, reresolveFile, and applyResolutions handlers hard-required getPausedOperationStatus() and kicked the user out with "No active merge, rebase, or cherry-pick conflicts to resolve." The paused-op status was only used to derive the resolver's ours/theirs/base refs, which conflict-tools treats as optional enrichment (without refs it skips the three-way diff and resolves from the conflict markers). Refs are now derived via getResolutionRefs(), which returns undefined when no operation is active rather than guessing at a stash ref that could be wrong. The apply-time paused-op stale guard is removed in favor of the existing per-file listUnmergedPaths guard, which covers every external staleness scenario (abort/continue/reset all clear unmerged entries) without wrongly refusing op-less sessions or merge --quit states. Fixes #5487
ianhattendorf
force-pushed
the
conflict-error-after-pull
branch
from
2a2d25c to
84d6740
Compare
Fixes #5487
Problem
The Resolve mode in the Commit Graph WIP details panel (AI conflict resolution) failed immediately with "No active merge, rebase, or cherry-pick conflicts to resolve." whenever the conflicted files had no in-progress Git operation — e.g. a
git stash pop/applyconflict, agit pullwith autostash where the re-apply conflicts, or the tree left conflicted aftergit merge --quit. In these cases Git records unmerged index entries but writes noMERGE_HEAD/CHERRY_PICK_HEAD/REVERT_HEAD/rebase state, sogetPausedOperationStatus()correctly returnsundefined.The entry point is gated purely on conflict status (correct), but three RPC handlers additionally required a paused operation, so the user could enter the flow only to be kicked out.
Fix
All changes are in
src/webviews/plus/graph/graphWebview.ts:resolveConflicts/reresolveFile— no longer require a paused operation. The status was only used to derive the resolver's ours/theirs/base refs, which@gitkraken/conflict-toolstreats as optional enrichment (without refs it skips the three-way diff and resolves from the conflict markers). Refs are now derived via a smallgetResolutionRefs()helper that returnsundefinedwhen no operation is active — deliberately not guessing at a stash ref (e.g.stash@{0}), which could be wrong and would feed the resolver a misleading three-way diff.applyResolutions— the apply-time paused-op stale guard is removed in favor of the existing per-filelistUnmergedPathsguard. That guard already covers every external staleness scenario (merge/rebase --abort,--continue,reset, external resolution all clear unmerged entries), and the removed guard had false positives (merge --quitleaves files conflicted but removesMERGE_HEAD) it should never have refused.No UI, protocol, or telemetry changes are needed — the resolve panel copy is already operation-agnostic, and telemetry records no operation type.
Testing
pnpm run checkandpnpm run test(1057 passing) both clean.Verified live against a prepared stash-pop repro (
UUfile, no operation state) across three rounds:reresolveFile(per-file retry with feedback): RPC completes, no "no longer in progress" error.git add-ing the conflicted file → Apply correctly refuses with "These files are no longer conflicted — nothing was applied.", disk untouched.MERGE_HEADpresent) still shows the paused-op banner and resolves normally; aftergit merge --abort, Apply refuses via the per-file guard with disk untouched.The error string "No active merge, rebase, or cherry-pick conflicts to resolve." never appeared in the panel, console, or logs across all scenarios.