fix(step): refuse to rebase or merge from a worktree mid-operation

[max-sixty]

The bug

With a rebase in progress (a conflicted stop, or a killed git), wt step rebase main reported success over a conflicted tree:

$ git rebase main          # stops on a conflict; HEAD detached mid-replay
$ wt step rebase main
○ Already up to date with main
$ echo $?
0

handle_rebase asked is_rebased_onto first. Mid-rebase, HEAD sits on a linear extension of the target, so that returns true and the function returns UpToDate before anything consults worktree_state.

wt merge from the same state failed differently but no better:

✗ Cannot merge: not on a branch (detached HEAD)
↳ To switch to a branch, run git switch <branch>

The hint names the one command that throws the rebase away instead of finishing it.

The fix

Both commit-replaying commands now check for an open operation before doing anything else. wt merge runs the check ahead of its branch check, so the open operation is what gets named rather than the detached HEAD it causes.

$ wt step rebase main
✗ Cannot rebase: a git operation is already in progress

The gate covers every state detection reports, not just rebase. Measured on the others beforehand: a rebase started mid-bisect ran and stacked a second operation on the first, and one started mid-merge or mid-cherry-pick died inside git's autostash (Cannot save the current index state, f: needs merge). None told the user what to do next.

Why it prescribes no remedy

An earlier draft of this branch carried a per-operation table of --continue/--abort hints. It was wrong on first contact with the long tail: git am borrows the rebase-apply directory, so an open am session was reported as a rebase and pointed at git rebase --continue, which git refuses outright:

$ git rebase --continue
fatal: It looks like 'git am' is in progress. Cannot rebase.

Adding an Am arm would have treated the enumeration as the fixable part. git status already answers this better than the table did, in git's own words and translations, for states worktrunk has no variant for:

$ git status
interactive rebase in progress; onto b162044
You are currently rebasing branch 'feat' on 'b162044'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)

It names the operation, the branch, the progress, and every way out including --skip, which the table never offered. So the table is gone rather than extended, and the refusal is a single line: it says what is blocked and why, and leaves the rest to the command every git user reaches for next.

Detection still returns a structured InProgressOperation rather than a display string, but now purely as detection: the only caller that reads a variant is the one classifying a rebase worktrunk itself just started.

The neighbouring RebaseConflict error took the same treatment. It forwards git's stderr in the gutter when it has it, and otherwise substituted two hint lines of its own:

↳ To continue after resolving conflicts, run git rebase --continue
↳ To abort, run git rebase --abort

That is the operation table again in miniature — one operation's remedies, minus --skip — and the one path that reaches it is the safety check for a rebase git reported as finished, where worktrunk knows least about what is actually open. It now prints its title, plus git's own words when git said any.

One detector

Two places probed the same files for the same answer: Repository::worktree_state for the gate, and WorkingTree::is_rebasing/is_merging for the wt list gutter symbols. They are now one method, WorkingTree::operation_in_progress, which Repository::operation_in_progress delegates to — the rename also retires a name that collided with wt list's unrelated WorktreeState.

Detection now runs in the order git status consults the state files, which is a change from the old wt list path: it checked rebase before merge. Nothing can reach the difference — no rebase backend writes MERGE_HEAD, checked against all three — but matching git's order is one less thing to reason about. wt list maps the operations without a gutter symbol (cherry-pick, revert, bisect) to None, so its output is unchanged.

The queued sequencer, now closed

Having one detector is what made the last gap worth closing. git cherry-pick A B that stops on A writes CHERRY_PICK_HEAD; resolving that stop with git commit instead of git cherry-pick --continue removes the file and leaves B queued:

$ git status
On branch main
Cherry-pick currently in progress.
  (run "git cherry-pick --continue" to continue)
$ ls .git/CHERRY_PICK_HEAD
ls: .git/CHERRY_PICK_HEAD: No such file or directory
$ cat .git/sequencer/todo
pick 1f07533 side1
pick 6b32540 side2

Git reads that same file to keep calling the sequence in progress, so detection reads it too: the first instruction word, pick or revert, exactly as git's own sequencer_get_last_command does.

The reason this waited for its own change is the risk of refusing a wt merge the user can't un-refuse, so the lifecycle is measured rather than assumed. The directory is gone once the sequence finishes, and gone after --quit or --abort; a single-commit cherry-pick never creates one; a rebase keeps its todo elsewhere, under rebase-merge/. An empty or unrecognized todo reports nothing, so the failure direction is the old behavior rather than a refusal with no way out.

Verification

The repro above, plus the merge, am, cherry-pick, revert, and bisect states, checked by hand against real repos: all five refuse, including am, which is now correct precisely because nothing here claims to know what am needs.

Three integration tests drive the real binary from a genuinely stopped operation (test_step_rebase_refuses_mid_rebase, test_merge_refuses_mid_rebase, test_merge_refuses_mid_merge). test_merge_refuses_mid_merge is what holds the broadened scope: a conflicted merge keeps HEAD on the branch, so it is the case the detached-HEAD check waves through. Narrowing the gate back to rebase-only turns it red, which I verified by making that edit and re-running.

The sequencer case is driven end to end from a real stopped pick — test_operation_in_progress_reads_the_queued_sequencer commits the resolution by hand, asserts CHERRY_PICK_HEAD is gone, and still expects a cherry-pick, so it can only pass through the sequencer read. It then runs git cherry-pick --quit and expects the state to clear, which is the false-refusal half. Running the same sequence against the built binary refuses where it previously reported ○ Already up to date with main.

Confirmed unchanged: already-up-to-date, fast-forward, true-rebase, and rebase-conflict output; a plain detached HEAD still gets the git switch hint, which is the right remedy when no operation is open; a sibling worktree mid-rebase does not block a clean one; wt list's gutter symbols.

Full gate green (4494/4494 tests, lints, fmt), plus cargo clippy --all-targets --features shell-integration-tests, which the gate doesn't compile.

Merged with main

main gained #3539, which extracted the failed-rebase classification into classify_rebase_failure, and #3549, which adds span_upstream — both inside handle_rebase. The conflict was semantic as well as textual: #3539's is_rebasing check still read the old string API (worktree_state()?.is_some_and(|s| s.starts_with("REBASING"))), which this branch removes, so resolving the markers alone left a type error. The resolution keeps #3539's classification and reads the structured enum instead:

let state = repo.operation_in_progress()?;
let is_rebasing = matches!(state, Some(InProgressOperation::Rebase));
return Err(classify_rebase_failure(e, is_rebasing, &integration_target));

All five of #3539's classification tests pass alongside the gate.

This was written by Claude Code on behalf of Maximilian

[worktrunk-bot]

Reviewing as a draft — flagging anything that looks worth a quick fix. Mark ready for a full review.

The detection consolidation reads cleanly, the queued-sequencer case is handled conservatively (empty/unrecognized todo → None, so the failure direction stays the old behavior), and the resume path is intact — after a conflicted wt merge, git rebase --continue clears the state so a re-run isn't refused. No stale callers of the removed worktree_state/is_rebasing/is_merging remain.

One minor doc nit inline.