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

Hi Junio,

Thanks for laying out the criteria for adding hooks.

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