Drop post-commit when the merge removed the worktree it runs in

[max-sixty]

Problem

wt merge prints ◎ Running post-commit: … and then spawns that pipeline into a path the removal has already emptied. post-commit is the only hook in the merge's background batch anchored on the feature worktree, and HookAnnouncer flushes after finish_after_merge has removed that worktree.

run_pipeline calls Repository::at on what's left, and git discovery walks up from it:

• Worktree outside the repository (the default ../{{ repo }}.{{ branch }}): nothing above it is a repository, so the runner logs failed to open repository for pipeline to .git/wt/logs/<branch>/<source>/post-commit/runner.log, which nothing reads back. The hook doesn't run.
• Worktree nested inside the repository ({{ repo_path }}/.worktrees/{{ branch | sanitize }}, one of the config page's own examples): discovery resolves to the primary worktree, so the hook's commands — arbitrary project code from .config/wt.toml — run against a checkout the user never chose.

#4026 documented both outcomes rather than fixing them.

Solution

The removal is the only thing that knows the anchor is gone, so it says so: spawn_hooks_after_remove calls HookAnnouncer::mark_worktree_removed(ctx.worktree_path), and the flush drops any pending pipeline anchored on a marked path. The survivors get the usual Running … line; each dropped pipeline gets its own warning.

▲ Skipped post-commit: mark (user) — worktree removed @ ~/code/myproject/.worktrees/feature
↳ To run commands in a worktree before it is removed, use pre-remove
◎ Running post-remove: cleanup (user); post-switch: notify (user); post-merge: sync (user) @ ~/code/myproject

Reading the fact from the removal rather than probing the filesystem is what makes the skip unconditional. The two removal paths leave the anchor in different states: the fast path renames the worktree into .git/wt/trash/ before the flush, but where that rename fails — cross-filesystem, permissions, Windows file locks — BackgroundFallbackMode::Detached spawns git worktree remove and the anchor is still on disk, intact, when the flush runs. A "does this path still hold git data" probe answers true there and spawns the hook into a worktree being deleted underneath it. The mark doesn't depend on which path ran.

Deciding at the flush keeps every case where the removal doesn't happen: --no-remove, merging on the target branch, merging from the primary worktree, and a removal blocked by a dirty worktree all leave the anchor in place, and post-commit runs there as before — as it does on wt step commit and wt step squash. Only wt merge can reach the drop: every other background hook anchors on a worktree its command keeps (post-merge, post-switch and post-remove all render against the destination).

There is no earlier moment to spawn it. Between the commit and the removal the worktree is rebased and runs pre-merge, so a background pipeline started there would race both.

Testing

test_merge_post_commit_runs_only_when_its_worktree_survives in tests/integration_tests/user_hooks.rs is parameterized over removal. The worktree is nested inside the repository so that a regression executes rather than merely fails: the hook writes git rev-parse --show-toplevel to a marker in the primary worktree.

• removed — asserts the marker never appears, and reports the resolved toplevel if it does. Dropping the partition writes the primary worktree's path there.
• kept (--no-remove) — the control: same hook, same marker path, worktree survives, and the marker names the feature worktree.

The mark is unconditional in spawn_hooks_after_remove, which every removal path reaches after its removal, so there is no fast-path/fallback branch left for a test to distinguish — the first revision of this PR put a holds_git_data probe there instead, and test (windows) caught the fallback taking the other answer.

The two merge announce snapshots now show the Skipped lines and a Running line without post-commit; both tests are renamed to the three hook types they still combine. cargo run -- hook pre-merge --yes passes.

Manual repro

A scratch repo whose post-commit hook is git rev-parse --show-toplevel > {{ repo_path }}/toplevel.txt, a feature worktree with one commit and one uncommitted file, then wt merge main --yes.

Without the drop, the nested layout runs the hook and the marker names the primary worktree, while the hook was anchored on .worktrees/feat:

/private/var/folders/.../tmp.6MtN6Ufppv/repo

With it:

Layout	Flags	Result
nested ({{ repo_path }}/.worktrees/{{ branch | sanitize }})	default (squash)	▲ Skipped post-commit, no marker
nested	--no-squash	▲ Skipped post-commit, no marker
external (../{{ repo }}.{{ branch }})	default (squash)	▲ Skipped post-commit, no marker
external	--no-remove	◎ Running post-commit, marker names the feature worktree

This was written by Claude Code on behalf of max-sixty

🤖 Generated with Claude Code

https://claude.ai/code/session_01QG3SjDDtiVkvmk3eZDc6vu

[worktrunk-bot]

Two claims the diff's prose makes that the code doesn't hold up.

The holds_git_data docstring now covers both callers with one cost model, but they read the answer in opposite directions: path_selector_directory withholds on true, run_hooks_background spawns on true. "A false positive costs only caution" is inverted for the new caller — a false positive there is exactly the wrong-worktree spawn the partition exists to prevent, which matters for whoever reads this before adding a third caller or loosening the check. Suggestion inline.

The skip is documented as unconditional (wt merge --help and hook.md: "reports post-commit as skipped instead of running it"), but it holds only where the removal's fast path runs. When stage_worktree_removal returns None — its own comment names cross-filesystem, permissions, and Windows file locking — the merge's BackgroundFallbackMode::Detached spawns a detached git worktree remove and leaves the anchor holding git data at the flush, so holds_git_data answers true and post-commit is announced and spawned into a worktree being deleted underneath it. That outcome isn't worse than today's, but it's a fifth exception neither the enumeration in handle_merge's comment nor the help text carries.