fix(remove, prune, merge): target the named worktree, retain shared branches

[worktrunk-bot]

Follow-up to the discussion on #3480: @max-sixty asked to have wt remove honor an explicit path generally. #3607 has since landed the resolution half, Repository::resolve_worktree, which turns a path into a worktree. This is the removal half, and it is the part resolution cannot decide: which worktree to act on is a naming question, whether the branch may be deleted is not.

Problem

wt remove threw the resolved answer away. For any non-current worktree it re-targeted by branch name, and prepare_worktree_removal mapped that branch back to git's first-listed worktree. Two failures followed, both silent.

The wrong worktree is removed. With feature checked out twice:

$ git worktree list
…/dup    [feature]
…/first  [feature]

$ wt remove …/first
◎ Removing feature worktree & branch in background (same commit as main, _)

…/dup is gone. …/first, the one named, is still there.

The survivor is left broken. The shared branch is deleted with it. Worktrunk deletes branches with git update-ref -d, git's compare-and-swap primitive, which unlike git branch -d does not refuse a ref that is checked out somewhere:

$ git worktree list
…/first  0000000 [feature]

$ git -C …/first rev-parse HEAD
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.

wt step prune reached the same deletion unattended, and wt merge reached it with a freshly integrated branch, so nothing else declined. A branch gets a second worktree only through git worktree add --force; worktrunk never does it itself.

Fix

Remove the worktree that was named. wt remove drops non-current worktrees via RemoveTarget::Path. wt step prune does the same: its candidates already carry a path, and targeting a stale entry by branch name resolved to a live worktree that the same prune had just skipped as too young, then removed it.

Retain a branch another worktree holds. One predicate, live_sibling_checkout, answers "would deleting this ref orphan a checkout?", and every path that can delete a branch asks it: prepare_worktree_removal's worktree and pruned-branch-only arms (covering wt remove, wt step prune, and the picker, which already targeted by path) and wt merge's finish. A hit forces BranchDeletionMode::Keep, the single chokepoint every deletion path honors, and names the surviving checkout:

$ wt remove …/dup
◎ Removing feature worktree in background
○ Branch feature retained; still checked out @ …/first

A sibling whose directory is already gone is stale metadata, not a checkout with anything to lose, so it does not retain: removing the last live checkout still deletes the branch.

-D is refused out loud. Everywhere else -D is the override that wins, so one that cannot be honored warns rather than passing quietly:

$ wt remove …/dup -D
◎ Removing feature worktree in background
▲ Branch feature retained despite -D; still checked out @ …/first

The ordinary single-checkout case is unchanged, and a retained branch skips the integration check entirely rather than computing a verdict it would discard.

#3480's duplicate-checkout hint now points at wt remove <path>, which this makes the safe answer.

Testing

Full gate green. New coverage, each case asserting the survivor still resolves HEAD, which is the corruption in question:

• remove: by path, by name, refused -D, the pruned-directory fallback, and the mirror case where a stale sibling must not retain.
• step prune: a stale entry whose branch is live in an age-skipped worktree. This test is what surfaced the wrong-worktree bug in prune.
• merge: merging a branch that a --force duplicate also holds.

Not addressed

wt step prune's summary counts candidates rather than outcomes, so a retained branch still reports ✓ Pruned 1 branch. The per-item line above it already says the branch was retained. Fixing the count means threading removal outcomes back through prune's accounting, which is a separate change.

This was written by Claude Code on behalf of Maximilian Roos

[worktrunk-bot]

This touches the data-loss surface (wt remove branch deletion in src/commands/repository_ext.rs), so flagging for a human call rather than self-approving — requesting review from @max-sixty.

The core fix reads well: removing by resolved path is unambiguous, and forcing Keep at the single chokepoint when a sibling checkout exists is the right shape to avoid orphaning. One residual gap in the same data-loss class, noted inline — the missing-directory prune fallback returns BranchOnly before the sibling-checkout guard runs, so it can still delete a branch that's live in a survivor. Narrow (requires the target's dir to be externally removed while a --force duplicate of an integrated branch survives), and it pre-dates this PR in the branch-targeted arm, but it sidesteps exactly the retention this PR adds.

Everything else — the paths_match symlink-aware matching, the JSON field, the output message, and the test coverage — looks correct.

[worktrunk-bot]

This early return lands before the Phase 5 branch_checked_out_at retention guard, so it isn't protected by it. If the target worktree's directory was externally removed (rm -rf) while a --force duplicate of the same branch survives, this prunes and falls through to RemoveResult::BranchOnly, which deletes the branch when integrated via the CAS git update-ref -d — the very call that bypasses git's checked-out-elsewhere guard and orphans the survivor at a null OID.

Narrow (integrated branch + missing dir + surviving --force sibling), and the branch-targeted arm has the same gap today, so not a blocker for this PR. But since the whole point here is to stop orphaning survivors, worth either detecting the sibling checkout before the BranchOnly fallback deletes the branch, or leaving a note that the missing-directory path is intentionally out of scope.

[worktrunk-bot]

Fixed in 6c9fb5b — the branch-only fallback now runs the same sibling-checkout detection before deleting the ref.

When a pruned removal resolves to BranchOnly and a still-intact worktree has the branch checked out (a --force duplicate), the branch is retained (deletion_mode forced to Keep) and the survivor is named in the output, so the CAS git update-ref -d never fires against a ref live in another worktree. Because both the path- and branch-targeted arms funnel through the one Resolved::BranchOnly handler in Phase 4, this closes the pre-existing branch-targeted gap too. A new branch_checked_out_at on RemoveResult::BranchOnly (mirroring the RemovedWorktree variant) carries the survivor path to the message; test_remove_pruned_dir_with_sibling_checkout_retains_branch covers rm -rf of the target dir with a surviving integrated duplicate.

[worktrunk-bot]

Reviewed the incremental since my last review (the fix(prune, tests) commit) — the prune refactor holds up: targeting stale/duplicate worktrees by their own path rather than re-resolving the branch to git's first-listed checkout is the right shape, computing the removal plan on the parallel scan (and deferring only Prunable, whose prep mutates metadata under the write lock) is sound, and swapping the per-worktree is_linked() probe for idx == 0 && !is_bare matches list_worktrees()'s documented ordering guarantee (main first, bare entries filtered). No new findings. My earlier data-loss-surface flag for @max-sixty still stands.

The affected tests (windows, advisory) red is not this PR. It's a cargo-affected tooling error, not a test failure:

Error: git diff stdout was not valid UTF-8: invalid utf-8 sequence of 1 bytes from index 112399

The failure fires after compilation, before any test runs, when cargo-affected decodes its git diff output to select affected tests. Two things pin it to the tooling rather than the change: the byte offset (112399) is past the PR's entire 66 KB three-dot diff, which contains no binary files, so the non-UTF-8 byte isn't in what this PR changed; and the string isn't one worktrunk emits. The job is advisory, and the required test (windows) passed, so the PR's own tests are green on Windows. A rerun should clear it — no code change warranted.