wt merge trusts stale local default-branch ref, can squash unrelated already-upstream commits into it

[starlightromero]

Bug Report

Description

wt merge, run from a feature-branch worktree that is itself correctly up to date with origin/<default-branch>, can still corrupt the primary checkout's local default-branch ref if that primary checkout has fallen behind origin/<default-branch>. Rather than fetching origin and using origin/<default-branch> as the merge/rebase target, wt merge appears to diff/squash against the primary checkout's local (stale) branch ref and then fast-forward that local ref via what looks like a local, non-network git push <path> HEAD:<default-branch>-style mechanism — bypassing any comparison against origin/<default-branch> first.

Repro

1. Primary checkout's local main is N commits behind origin/main (e.g. left checked out on an unrelated feature branch for a while, never fetched/fast-forwarded).
2. From a separate worktree, correctly created via wt switch --create <branch> --base origin/main (confirmed zero divergence from origin/main at creation time), add one commit, push it, open a PR containing only that one commit.
3. Run wt merge from within that worktree.

Observed

wt merge reported "Squashing 13 commits into a single commit" and produced a squash commit combining the 1 real commit with 12 already-merged-to-origin/main commits (visible by PR title in the generated squash-commit message) into the local default-branch ref of the primary checkout — not the worktree's own branch. git reflog on the affected branch showed a push action at the corrupted commit, consistent with a local ref update rather than a real network operation.

Impact

In our case no network push occurred (origin/main was untouched throughout — verified via git fetch origin + git log origin/main before and after; the real PR remained open/unmerged on GitHub the whole time), so it was recoverable via git branch -f main origin/main. But had that local main subsequently been pushed by any later action, it would have introduced a squash commit duplicating content already on origin/main under new commit SHAs.

Relationship to #3471

Same underlying class as #3471 (wt's cached default-branch state not refreshing from origin/HEAD) — trusting a local ref instead of origin/<default-branch> — but a different subcommand (merge rather than switch --create) and a more dangerous consequence: it mutates/corrupts an existing local branch ref (potentially the primary checkout's) rather than just creating a new branch that's missing some upstream content.

Suggested fix

wt merge should fetch origin and use origin/<default-branch> as its merge/rebase target (or at minimum warn/fail) whenever the local default-branch ref is behind origin/<default-branch>, rather than trusting the local ref uncritically — mirroring whatever fix addresses #3471 for wt switch --create.

Workaround

Before running wt merge, ensure the primary checkout's local default branch is current: git fetch origin && git log origin/<default-branch>..<default-branch> (check for unpushed-only local commits first) && git branch -f <default-branch> origin/<default-branch> if safe. Or bypass wt merge entirely and merge the PR directly via gh pr merge <PR> --squash --delete-branch.

Environment

• worktrunk version: 0.68.0 (Homebrew)

[worktrunk-bot]

Thanks for the detailed report — I reproduced this deterministically, and your trace is spot on, right down to the push entry in the target's reflog.

Root cause. wt merge resolves its target to the local default-branch ref (require_target_branch), then squashes/rebases the span merge-base(local-target, HEAD)..HEAD. When the primary checkout's local main is behind origin/main and the feature branch descends from the newer origin/main tip (your --base origin/main), that merge-base falls back at the stale local tip, so the span sweeps in every commit between them — the ones already on origin/main. The squash folds them into a single commit, and the fast-forward that lands it is a local git push <git-common-dir> HEAD:<target> (handle_push) — hence the push in the reflog and the local-only ref divergence, with origin/main untouched.

On the suggested fix. Targeting origin/<default> directly would collide with two things: worktrunk is local-first (wt merge deliberately never fetches — network never blocks a command), and there's an existing regression test, test_merge_removes_branch_when_local_main_diverged_from_upstream, that treats a diverged local/upstream main as a supported case and asserts the merge should succeed against the local ref. So "use the upstream as target" isn't a drop-in change.

Your "at minimum warn/fail" alternative is the better fit, and it lines up with worktrunk's own Data Safety posture ("prefer failure over silent loss"). It can be done local-only (no fetch) using refs already present: fail when merge-base(HEAD, origin/<target>) is not an ancestor of the local <target> — i.e. the operation would re-fold commits already reachable from origin/<target>. That condition fires on your scenario but stays quiet on the legitimately-diverged case above (where the span is just the feature's own commit), so it wouldn't regress that flow. Whether that should hard-fail vs. warn, and how it interacts with --no-squash/--no-rebase, is a design call I'll leave to a maintainer.

Recovery / workaround is as you found — origin/main is never touched, so git branch -f <default> origin/<default> (from a worktree where it isn't checked out) restores it; keeping the primary checkout's local default current before wt merge avoids it entirely.

Reproduction and evidence

Local main two commits behind origin/main; feature created off origin/main with one real commit; wt merge --yes --no-hooks:

◎ Squashing 3 commits into a single commit (3 files, +3)...
  Combined commits:
  - upstream commit 1 (already on origin)
  - upstream commit 2 (already on origin)
  - the one real feature commit
✓ Squashed @ 3584a76
✓ Merged to main (1 commit, 3 files, +3)

After the merge:

$ git merge-base --is-ancestor origin/main main && echo ancestor || echo "DIVERGED"
DIVERGED          # origin/main content now duplicated under a new squash SHA in local main
$ git reflog main -1
3584a76 main@{0}: push

origin/main is unchanged throughout (verified before/after), matching your report: recoverable locally, but a subsequent push of that local main would introduce a squash duplicating already-upstream content under new SHAs.

Steps:

1. Bare origin; clone; base commit on main; push.
2. Advance origin/main by 2 commits from a second clone (stand-in for merged PRs).
3. In the primary checkout: git fetch origin but leave local main stale (don't fast-forward).
4. wt switch --create feature --base origin/main; add one commit.
5. wt merge from the feature worktree.

Same underlying class as #3471 (trusting a local ref over origin/<default>), but here it mutates an existing ref rather than seeding a new branch — the more dangerous consequence you called out. A maintainer will weigh the guard and prioritize.