Repository navigation
docs(hook): say post-merge runs in the destination worktree regardless of removal - #4071
Merged
Merged
Conversation
…s of removal Closes #4070
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
wt hook --helplists the three cases where a hook'scwddiffers fromworktree_path, and thepost-mergeentry qualifies itself with "with removal":That condition does not exist.
post-mergeis anchored on the merge destination unconditionally —approve_merge_planadds it atdestination_pathoutside thewill_removebranch, andfinish_after_mergeregisters 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-removeboth 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-removecase explicitly since that is the one the old wording got wrong:Source is
after_long_helpinsrc/cli/mod.rs; the three generated mirrors are regenerated bytest_docs_are_in_sync. No--helpsnapshot captures this text.Testing
test_merge_post_merge_runs_in_destination_with_no_removemerges a feature worktree with--no-removeand apost-mergehook 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, andcargo clippy --all-targetsall pass locally.Closes #4070 — automated triage