Skip to content

docs(hook): say post-merge runs in the destination worktree regardless of removal - #4071

Merged
max-sixty merged 1 commit into
mainfrom
fix/issue-4070
Sep 12, 2026
Merged

max-sixty merged 1 commit into
mainfrom
fix/issue-4070

Conversation

@worktrunk-bot

Copy link
Copy Markdown
Collaborator

Problem

wt hook --help lists the three cases where a hook's cwd differs from worktree_path, and the post-merge entry qualifies itself with "with removal":

  • post-merge with removal: the active worktree is gone, so the hook runs in the target worktree

That condition does not exist. post-merge is anchored on the merge destination unconditionally — approve_merge_plan adds it at destination_path outside the will_remove branch, and finish_after_merge registers it there whether or not the feature worktree was removed. The stated reason is wrong too: the hook runs in the destination because it is about the destination, not because the source worktree happens to be gone.

The qualifier is also the only place on the page that says this. The hook-type table ("Runs in the target branch worktree if it exists, otherwise the primary worktree") and the merge-pipeline paragraph ("post-merge, post-switch and post-remove in the destination") both state the unconditional behavior, so the page contradicts itself — and the bullet is the version a reader lands on when they are specifically asking which tree the hook sees.

The failure it invites is concrete: under --no-remove both worktrees are on disk, and a hook written from this bullet — a deploy, a build, an external freshness check — inspects the pre-merge feature worktree while reporting on the integrated result. #4070 asks exactly this question.

Solution

Replace the qualifier with the behavior the code implements, naming the --no-remove case explicitly since that is the one the old wording got wrong:

  • post-merge: the hook runs in the target branch's worktree (the primary worktree if the target has none), including under --no-remove, where the merged worktree worktree_path names is still on disk

Source is after_long_help in src/cli/mod.rs; the three generated mirrors are regenerated by test_docs_are_in_sync. No --help snapshot captures this text.

Testing

test_merge_post_merge_runs_in_destination_with_no_remove merges a feature worktree with --no-remove and a post-merge hook that writes a marker relative to its cwd, then asserts the marker lands in the destination worktree and not in the preserved feature worktree. It passes against unchanged code — the behavior was already correct, and the test pins it so the documented contract cannot drift back.

integration_tests::merge:: (153 tests), integration_tests::help:: (59), integration_tests::readme_sync:: (18), cargo fmt --check, and cargo clippy --all-targets all pass locally.

Closes #4070 — automated triage

@worktrunk-bot worktrunk-bot added the automated-fix Automated CI fix label Sep 12, 2026
@max-sixty
max-sixty merged commit f6b699a into main Sep 12, 2026
37 of 47 checks passed
@max-sixty
max-sixty deleted the fix/issue-4070 branch September 12, 2026 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated-fix Automated CI fix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Docs suggestion: destination-worktree context checks after merge

2 participants