Re: [PATCH v2 0/4] worktree: add lifecycle hooks

Hi Junio,

Thanks for laying out the criteria for adding hooks.

But for the hooks proposed in this topic, I do not think such an
exception applies.

I agree that a wrapper is sufficient when all callers are under the
user's control. The problem I am trying to solve is that the component
which needs the notification does not control the component invoking
Git.

For example, devenv may register lifecycle handling for a repository,
but worktrees can subsequently be created or removed by an IDE, a
coding agent, another worktree tool, a script, or the user directly.
Requiring each of those callers to discover and use the same wrapper
makes the notification optional in practice. A repository hook provides
one place where that lifecycle behavior can be registered regardless of
which caller invokes Git.

"git worktree prune" is also difficult to reproduce reliably in a
wrapper. One invocation can remove zero or many administrative entries,
and Git knows exactly which entries it actually removes. A wrapper could
compare "git worktree list" before and after the command, but that is
not an authoritative event stream, can race another worktree operation,
and has limited information when an entry is already damaged.

Alexander provided another concrete example later in the thread: Xcode
and several related tools keep substantial path-keyed state outside the
worktree. Agents invoking "git worktree remove" or "git worktree prune"
directly leave many gigabytes of state behind even though a cleanup
wrapper exists. Phillip also mentioned having an unpublished add-hook
patch for copying per-worktree files such as config.mak.

That said, I take the point about avoiding a proliferation of hooks.
Instead of adding three separate hook names, would a single
"post-worktree" hook address that concern? It could use a fixed
interface such as:

    post-worktree add    <id> ""         <new-path>
    post-worktree move   <id> <old-path> <new-path>
    post-worktree remove <id> <old-path> ""

All paths would be absolute. Pruning would issue one "remove" event for
each entry actually pruned, and none under --dry-run. As with the
current series, the hook would only report an operation that has taken
effect and could not undo it.

This would also address Caleb's comment about passing information Git
already has rather than requiring the hook to query it, and it avoids
using the argument count to distinguish events.

Would that narrower interface, together with the need to observe
operations from callers that cannot be required to use a wrapper, meet
the bar for a native hook? If not, I would appreciate guidance before
spending time on a reroll.

Thanks,
Domen