Hello,
I'd like to discuss adding native hooks for worktree lifecycle events.
Git currently invokes `post-checkout` after `git worktree add` when a checkout is performed. This makes it possible to detect some worktree creation cases indirectly. There does not appear to be a native hook for other worktree lifecycle operations such as:
git worktree add
git worktree remove
git worktree move
git worktree lock
git worktree unlock
git worktree pruneAs a result, tools which want to react to these operations have to wrap `git worktree` or compare the worktree state before and after a command. They cannot observe an invocation which bypasses their wrapper.
One concrete use case is git-hooks-ext, which provides higher-level events for Git operations. It currently has to implement worktree events by wrapping `git worktree` and comparing the output of `git worktree list --porcelain` before and after the command.
Would it make sense for Git to expose worktree lifecycle events directly?
One possibility would be separate post-operation hooks such as:
post-worktree-add
post-worktree-remove
post-worktree-move
post-worktree-lock
post-worktree-unlockAnother possibility would be a single hook, similar in spirit to `reference-transaction`, which reports worktree lifecycle changes. An illustrative payload could look like:
add <path>
remove <path>
move <old-path> <new-path>
lock <path>
unlock <path>
prune <path>A single hook may be useful for operations such as `git worktree prune`, where one command can remove multiple administrative entries. It could also leave room for `git worktree repair`, although I am unsure whether repair belongs to the same interface.
For the use case I have in mind, these hooks would only need to notify observers after a successful operation. They would not need to veto the operation.
Before attempting an implementation, I'd like to know whether this would fit Git's hook model, and whether a single lifecycle hook or individual operation hooks would be preferable. I would also appreciate guidance on whether a stable worktree identifier should be exposed in addition to the path.
Thanks, Maciej Ciemborowicz