Add headless overwrite semantics to merge_conflicts and the merge CLI verb - #28
Merged
Conversation
… verb Headless/MCP merges could never refresh an existing merged file: the overwrite YesNo prompt fell through to HeadlessMergeNotifier's fixed non-destructive default (No), with the reason buried in stderr prompt text - and dryRun could only predict that skip, never whether an already-merged file would auto-solve (docs/bugs/function-level-merge-gap-handling.md, "Related, lesser finding"). - FileMerger.MergeConflictsHeadless gains an overwrite parameter; without it an existing output is a clearly-reported skip (ReportOutputExistsSkip, naming the way out) instead of an unanswerable prompt; with it the merge refreshes the existing output. Interactive GUI paths keep their real prompt unchanged. - MCP merge_conflicts gains overwrite (echoed in the result); CLI merge gains --overwrite in both hosts. - The Vortex extension's resolve flow passes overwrite: true for both the preview and the confirmed merge - a Vortex-driven re-merge after a mod update is exactly the refresh case. Documented version-skew behavior against pre-overwrite servers. - New integration test: real double-merge round trip (skip-with-reason without overwrite, dry-run prediction either way, actual refresh with). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GXAuGMLB44T5Zv5o5ZzKah
…write # Conflicts: # .gitignore
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.
Summary
Fixes the "Related, lesser finding" from
docs/bugs/function-level-merge-gap-handling.md(the doc itself lands with PR #27): headless/MCP merges could never refresh an existing merged file. The overwrite YesNo prompt fell through toHeadlessMergeNotifier's fixed non-destructive default (No), so any conflict whose merged output already existed was skipped with the reason visible only as stderr prompt text — anddryRuncould only predict that skip, never whether an already-merged file would actually auto-solve. For a mod manager re-merging after a source mod updates (the Vortex extension's whole flow), that made refresh impossible.Changes
FileMerger.MergeConflictsHeadlessgainsoverwrite(default false). Without it, an existing output is a clearly reported skip (ReportOutputExistsSkip: names the file and the way out —--overwrite/overwrite: true) instead of an unanswerable prompt. With it, the merge refreshes the existing output. The interactive GUI paths keep their real, answerable prompt unchanged.merge_conflictsgainsoverwrite(echoed in the result object alongsidedryRun);dryRun + overwritenow answers "would this auto-solve?" for already-merged files.mergegains--overwritein both hosts; usage text updated.overwrite: truefor both the preview and the confirmed merge — the preview must predict what the real run will do.MergeConflictsArgs.overwrite's doc comment covers version skew: a pre-overwrite WSM server ignores the unknown argument and degrades to its previous skip behavior rather than erroring.Tests
New integration test (real spawned Headless process): double-merge round trip — skip-with-reason and unchanged mtime without
overwrite, dry-run predictions both ways, actual refresh withoverwrite: true. Full pipelines green:dotnet test128/128, extension 200 unit / 215 with integration,dotnet format --verify-no-changesclean.Note: two pre-existing integration tests were failing before this change on this machine — a populated
MergeInventory.xmlleft inbin/Debugby the live bug-session run was leaking into "empty mods folder" fixtures. Deleted the stale build-output file (backed up beforehand); not a code issue.🤖 Generated with Claude Code
https://claude.ai/code/session_01GXAuGMLB44T5Zv5o5ZzKah