Is this `wt land [PR]` alias a sound pattern?

[mavam]

I wanted a single command that squash-merges a GitHub PR, updates the local default branch, and removes the corresponding worktree.

I ended up with this alias:

[[aliases.land]]
merge-pr = '''
{% if args | length == 0 %}
gh pr merge --squash --match-head-commit {{ commit }}
{% elif args | length == 1 %}
gh pr merge {{ args[0] }} --squash --match-head-commit "$(gh pr view {{ args[0] }} --json headRefOid --jq .headRefOid)"
{% else %}
echo "usage: wt land [PR]" >&2; exit 2
{% endif %}
'''

[[aliases.land]]
sync-main = "git -C {{ worktree_path_of_branch(default_branch) }} pull --ff-only --prune {{ remote }} {{ default_branch }}"

[[aliases.land]]
cleanup = '''
{% if args | length == 0 %}
wt remove {{ branch }}
{% else %}
branch="$(gh pr view {{ args[0] }} --json headRefName --jq .headRefName)"
if git show-ref --verify --quiet "refs/heads/$branch"; then
  wt remove "$branch"
fi
{% endif %}
'''

Usage:

wt land       # From the PR worktree
wt land 36    # From main or another worktree

Does this make sense as a Worktrunk composition, or am I missing a simpler or safer approach?

In particular:

• Is wt remove expected to recognize the branch as integrated after a squash merge?
• Is resolving the PR head branch after merging sufficiently robust?
• Are there Worktrunk primitives that would avoid the explicit gh and git plumbing?

[worktrunk-bot]

Thanks — this is a reasonable composition, and the [[aliases.land]] block form is the right shape for it: blocks run in order and a step failure aborts the rest, so a failed merge-pr never reaches cleanup. I ran your three questions against a scratch repo with a real remote-side squash merge; notes below, then a revised version.

1. Yes, and you need less than you think. wt remove's branch cleanup runs six checks; #5 (simulated merge adds nothing) and #6 (patch-id match against a single squash commit on the target) are exactly the squash-merge cases.

The useful part: the integration check measures against the default branch or its upstream when the upstream is strictly ahead. So git fetch alone is enough — you don't have to get the local main ref moved before cleanup runs. With local main deliberately left stale:

$ git log --oneline -1 main          # 8aa768e initial
$ git log --oneline -1 origin/main   # da14262 feat: everything (#36)
$ wt remove feature
✓ Removed feature worktree & branch (tree matches origin/main, ⊂)

That matters because {{ worktree_path_of_branch(default_branch) }} renders to '' when the default branch isn't checked out anywhere (bare-repo layouts, or the main worktree parked on some other branch) — and git -C '' is a no-op, not an error. Your sync-main then quietly pulls main into whatever worktree you're standing in rather than failing. Worth a -n guard regardless of ordering.

One boundary: the patch-id fallback walks at most 500 commits back on the target side. Landing promptly stays well inside it; a branch squash-merged hundreds of commits ago needs -D.

2. Resolving the head branch is fine; the guard isn't. headRefName survives both the merge and the head-branch deletion — I checked a merged PR here whose ref is a 404 and the field still returns. Three gaps:

• --match-head-commit "$(gh pr view N --json headRefOid …)" is a no-op. It asserts the head equals what you read from the same API a moment earlier, so it can only fail on a sub-second race. Your zero-arg path is the meaningful one — {{ commit }} is your local HEAD, so it asserts the PR head is what you actually reviewed. In the numbered path there's no such local reference; I'd drop the flag rather than let it read as a guard.

• Fork PRs. headRefName names a branch in the fork; a same-named local branch is unrelated, and git show-ref will happily confirm it. Gate on isCrossRepository. (The blast radius is bounded — wt remove main refuses with The main worktree cannot be removed — but an unrelated linked worktree is fair game.)

• The PR may not have merged. gh pr merge can succeed by enqueuing on a merge-queue branch rather than merging. cleanup then runs against an unmerged PR, and wt remove removes the worktree and exits 0, just declining the branch:

  ✓ Removed unmerged worktree (3 files · 55 B)
  ↳ Branch unmerged; to delete, run wt remove -D unmerged
  

  Recoverable, since the branch survives — but surprising. A state = MERGED check as its own block closes it.

3. No primitive wraps gh pr merge — steps 1–2 stay yours. But the whole cleanup step collapses into wt step prune (experimental): same integration criteria, no gh round-trip, no branch-name resolution, and it works from any worktree. Verified against the same stale-main setup:

$ wt step prune --dry-run --min-age=0
○ feat — tree matches origin/main
↳ 1 worktree & branch would be removed (dry run)

--min-age=0 is needed (the default 1d guard exists so a worktree just branched off main isn't reaped for looking "merged"). The tradeoff is scope: it prunes every integrated worktree, not just this PR's. If that suits you, land becomes merge-pr → verify → sync-main → wt step prune --min-age=0 and the fork/collision question disappears entirely.

Revised alias

[[aliases.land]]
merge-pr = '''
{% if args | length == 0 %}
gh pr merge --squash --match-head-commit {{ commit }}
{% elif args | length == 1 %}
gh pr merge {{ args[0] }} --squash
{% else %}
echo "usage: wt land [PR]" >&2; exit 2
{% endif %}
'''

[[aliases.land]]
verify = '''
{% if args | length == 0 %}
state=$(gh pr view --json state --jq .state)
{% else %}
state=$(gh pr view {{ args[0] }} --json state --jq .state)
{% endif %}
[ "$state" = MERGED ] || { echo "PR is $state, not MERGED - skipping cleanup" >&2; exit 1; }
'''

[[aliases.land]]
sync-main = '''
git fetch --prune {{ remote }} {{ default_branch }}
main_wt="{{ worktree_path_of_branch(default_branch) }}"
if [ -n "$main_wt" ]; then
  git -C "$main_wt" merge --ff-only {{ remote }}/{{ default_branch }}
fi
'''

[[aliases.land]]
cleanup = '''
{% if args | length == 0 %}
wt remove {{ branch }}
{% else %}
if [ "$(gh pr view {{ args[0] }} --json isCrossRepository --jq .isCrossRepository)" = false ]; then
  branch=$(gh pr view {{ args[0] }} --json headRefName --jq .headRefName)
  if git show-ref --verify --quiet "refs/heads/$branch"; then
    wt remove "$branch"
  fi
fi
{% endif %}
'''

sync-main fetches unconditionally (that's the part cleanup depends on) and only fast-forwards the default-branch worktree if one exists — no second network round-trip, and no silent wrong-worktree pull when it doesn't. wt config alias dry-run land -- 36 renders both arg shapes if you want to eyeball it before running.

How this was checked

Built from 286004f1ebe5f6563c772be24987394144a29215. Scratch repo with a bare "remote", a third clone standing in for GitHub's squash-merge button (git merge --squash + push), and the working clone's local main deliberately left stale.

• wt remove <branch> after git fetch only → Removed feature worktree & branch (tree matches origin/main, ⊂). Target selection is in integration_targets: local behind upstream → upstream becomes the target.
• wt remove on an unmerged branch → worktree removed, exit 0, --format=json reports "branch_outcome": "retained_unmerged".
• wt remove main → ✗ The main worktree cannot be removed, exit 1.
• Pipeline abort: a two-block alias whose first step exit 1s never printed the second step's output; exit 1.
• worktree_path_of_branch with the default branch checked out nowhere → renders git -C '' pull …; git -C '' runs in the current directory and exits 0.
• headRefName on a merged PR whose head ref returns 404 → still returns the name.
• wt step prune --min-age=0 → removed the same worktree, tree matches origin/main.
• --match-head-commit and -d, --delete-branch confirmed against gh pr merge --help (gh 2.96.0). Note -d deletes the local branch too, so leaving it off is right here.

Unrelated but adjacent: #3723 — wt remove invoked as an alias step loses subdirectory preservation, so in a monorepo wt land will drop you at the repo root rather than the corresponding subdirectory.

A maintainer may have views on whether any of this belongs in Tips & Patterns — it's a recurring shape.