Group of 3 Under the hood
Worktree create/remove hook handling was refined: fewer spurious errors and clearer checks for whether a hook applies
What
- In the worktree-create flow, if no hook commands ran at all, the code used to always throw a "hook is configured but did not run" error. Now it first checks whether any
WorktreeCreatehook is actually configured, and silently continues if none is, only throwing when a hook is genuinely configured but failed to run. - The decision of whether to use a
WorktreeCreatehook (instead of falling back to the built-in git worktree flow) now goes through a renamed gate that checks either an existing predicate or the presence of a registeredWorktreeCreatehook. - The existing
WorktreeCreate/WorktreeRemovehook events are now also checked through a broader capability lookup (not just whether hooks are registered for them), used to decide whether the worktree create/remove UI is shown at all.
Why These changes reduce spurious "hook is configured but did not run" errors when no worktree hook is set up, and make the logic for whether worktree create/remove hooks and UI are active more consistent.
Names in the bundleWorktreeCreateWorktreeRemove
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
What other conditions the broader capability check considers beyond hook registration is not stated.