ux(worktrees): rebase reports conflict file names only — no hunk detail and no sanctioned resolve path #21

New issue

Closed

opened 2026-07-11 21:45:48 +00:00 by hexajon · 1 comment

hexajon commented

2026-07-11 21:45:48 +00:00

(Migrated from codeberg.org)

Gap (hit live, 2026-07-10, an earlier branch)

madt_worktrees action=rebase onto=main on a conflicted branch reports:

Conflict rebasing <branch> onto main — 1 file(s); aborted, worktree left clean
  docs/adr/README.md

Clean abort is the right default, but the agent is then stuck:

No conflict detail — file names only. No hunks, no ours/theirs context, nothing to plan a resolution from.
No sanctioned resolve path — raw git rebase <base> is steered to the madtea tools (which auto-abort), and the steering's carve-out for git rebase --continue is unreachable because you can never get INTO a conflicted rebase. The only workaround today is manual tree surgery: copy the base version of the conflicted file over the branch's, re-apply the branch's intent by hand, commit, and let the 3-way merge resolve on identical hunks (what that branch ended up doing for the ADR index).

Ask

Either (or both):

Conflict transparency: on abort, include the conflicted hunks (bounded, per file) in the result — ours/theirs/base excerpts — so the agent can plan the manual reconciliation without a resolve mode.
A sanctioned resolve flow: e.g. action=rebase resolve=true leaves the conflicted rebase in progress in the worktree (worktree-scoped, never the primary checkout) and the steering blesses git add <file> + git rebase --continue inside it; or a documented recipe in madt_help(topic="worktrees") for the tree-surgery pattern.

Whichever shape, the goal is: a conflicted rebase must have a first-class path forward, not just a clean dead end.

## Gap (hit live, 2026-07-10, an earlier branch) `madt_worktrees action=rebase onto=main` on a conflicted branch reports: ``` Conflict rebasing <branch> onto main — 1 file(s); aborted, worktree left clean docs/adr/README.md ``` Clean abort is the right default, but the agent is then stuck: - **No conflict detail** — file names only. No hunks, no ours/theirs context, nothing to plan a resolution from. - **No sanctioned resolve path** — raw `git rebase <base>` is steered to the madtea tools (which auto-abort), and the steering's carve-out for `git rebase --continue` is unreachable because you can never get INTO a conflicted rebase. The only workaround today is manual tree surgery: copy the base version of the conflicted file over the branch's, re-apply the branch's intent by hand, commit, and let the 3-way merge resolve on identical hunks (what that branch ended up doing for the ADR index). ## Ask Either (or both): 1. **Conflict transparency:** on abort, include the conflicted hunks (bounded, per file) in the result — ours/theirs/base excerpts — so the agent can plan the manual reconciliation without a resolve mode. 2. **A sanctioned resolve flow:** e.g. `action=rebase resolve=true` leaves the conflicted rebase in progress in the worktree (worktree-scoped, never the primary checkout) and the steering blesses `git add <file>` + `git rebase --continue` inside it; or a documented recipe in `madt_help(topic="worktrees")` for the tree-surgery pattern. Whichever shape, the goal is: a conflicted rebase must have a first-class path forward, not just a clean dead end.

hexajon commented

2026-07-11 22:08:58 +00:00

(Migrated from codeberg.org)

Amendment from later in the same session: a sanctioned conflicted-PR path DOES exist — madt_orchestrate reconcile=<pr> (merge base into head, continue/abort rails) — and it resolved a recent conflicted-PR case well. Two residual gaps stand:

It's PR-scoped: a conflicted branch with no PR yet (e.g. a stale worktree branch pre-finish) still has no sanctioned resolve path — madt_worktrees action=rebase aborts and raw git rebase is steered away.
Discoverability: madt_worktrees rebase's conflict-abort message doesn't mention reconcile or any next step, and madt_finish's merge-405 advice doesn't either (that part is #22). I only found reconcile because madt_prs action=merge's error names it.

So the ask narrows to: give the no-PR case a path (or bless reconcile pre-PR), and cross-link the existing rails from the rebase/finish failure messages.

Amendment from later in the same session: a sanctioned conflicted-**PR** path DOES exist — `madt_orchestrate reconcile=<pr>` (merge base into head, continue/abort rails) — and it resolved a recent conflicted-PR case well. Two residual gaps stand: 1. It's PR-scoped: a conflicted branch with no PR yet (e.g. a stale worktree branch pre-finish) still has no sanctioned resolve path — `madt_worktrees action=rebase` aborts and raw `git rebase` is steered away. 2. Discoverability: `madt_worktrees rebase`'s conflict-abort message doesn't mention reconcile or any next step, and `madt_finish`'s merge-405 advice doesn't either (that part is #22). I only found reconcile because `madt_prs action=merge`'s error names it. So the ask narrows to: give the no-PR case a path (or bless reconcile pre-PR), and cross-link the existing rails from the rebase/finish failure messages.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#21

No description provided.

Rows
Columns