Re: [PATCH v1 0/3] worktree: add post-worktree-add and post-worktree-remove hooks
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jul 10, 2026, 09:34 UTC
- Message-ID
- <0f37a01d-c39e-47b3-b8e9-48cdd42672df@gmail.com>
- In-Reply-To
- <7c8b4673-37ac-45fa-ad8c-a1dc09afe5fe@mtasv.net>
Hi Domen
On 10/07/2026 00:36, Domen Kožar wrote:
Show 8 quoted lines
> > Today there is no reliable trigger to set that up when a worktree > appears: post-checkout does not fire for --no-checkout or --orphan > and cannot be told apart from a plain checkout. Nothing at all fires > when a worktree goes away, so stale databases and services pile up > after "git worktree remove" or a manual rm followed by "git worktree > prune". Wrapping the worktree commands only helps when every tool, > human or agent, goes through the wrapper.
I agree a hook that's run after the worktree is added is useful (I have a patch for it that I've never got round to cleaning up and sending so thank you for working on this). It is useful for copying across untracked files to the new worktree like "config.mak".
> Patch 1 adds a post-worktree-add hook that fires after the working > tree is fully set up. Patch 2 adds post-worktree-remove for "git > worktree remove". Patch 3 extends it to "git worktree prune" so that > manually deleted worktrees are also observed.
I don't have a strong opinion on a hook running when a worktree is removed - an IDE that cares about that could set up a filesystem watch on the directory but I guess adding a hook doesn't do any harm.
Show 7 quoted lines
> Two design points I would especially appreciate feedback on: > > * post-worktree-add runs after post-checkout and is skipped when > post-checkout fails. An argument could be made that it should run > whenever the worktree was created, regardless of the earlier > hook's exit status, since tooling registering worktrees would > otherwise miss one that does exist.
Looking at the existing code, if the checkout fails then we remove the worktree because "is_junk == 1" when remove_junk() is called via atexit() so I think it is correct to skip the new hook in that case.
The new hook is run after the checkout, but before the post-checkout hook - we should document their relative order. I see the hook is run in the new worktree and passed the absolute directory and worktree id. I'm wondering if either of those is useful if we're running the hook in the new worktree.
> * for entries pruned because their gitdir file points to a location > that no longer exists, the hook receives the recorded path; when > the path cannot be determined at all (missing or corrupt gitdir > file) it receives an empty string.
So the hook knows a worktree was removed but not which one?
Thanks
Phillip
Show 19 quoted lines
> Thanks, > Domen > > Domen Kožar (3): > worktree: add post-worktree-add hook > worktree: add post-worktree-remove hook > worktree: run post-worktree-remove hook when pruning > > Documentation/githooks.adoc | 41 +++++++++++++ > builtin/worktree.c | 73 ++++++++++++++++++----- > t/t2400-worktree-add.sh | 113 ++++++++++++++++++++++++++++++++++++ > t/t2401-worktree-prune.sh | 88 ++++++++++++++++++++++++++++ > t/t2403-worktree-move.sh | 44 ++++++++++++++ > worktree.c | 1 - > worktree.h | 6 +- > 7 files changed, 347 insertions(+), 19 deletions(-) > > > base-commit: f85a7e662054a7b0d9070e432508831afa214b47