On Tue, Jan 25 2022, Emily Shaffer wrote:

quoted

* ab/config-based-hooks-2 (2022-01-07) 17 commits
  (merged to 'next' on 2022-01-19 at 594b6da22c)
 + run-command: remove old run_hook_{le,ve}() hook API
 + receive-pack: convert push-to-checkout hook to hook.h
 + read-cache: convert post-index-change to use hook.h
 + commit: convert {pre-commit,prepare-commit-msg} hook to hook.h
 + git-p4: use 'git hook' to run hooks
 + send-email: use 'git hook run' for 'sendemail-validate'
 + git hook run: add an --ignore-missing flag
 + hooks: convert worktree 'post-checkout' hook to hook library
 + hooks: convert non-worktree 'post-checkout' hook to hook library
 + merge: convert post-merge to use hook.h
 + am: convert applypatch-msg to use hook.h
 + rebase: convert pre-rebase to use hook.h
 + hook API: add a run_hooks_l() wrapper
 + am: convert {pre,post}-applypatch to use hook.h
 + gc: use hook library for pre-auto-gc hook
 + hook API: add a run_hooks() wrapper
 + hook: add 'run' subcommand

 More "config-based hooks".

 Will cook in 'next'.
 source: [ref]

Very excited to see this one go in and looking forward to the next set!
By the way, this reduced the number of patches Google is carrying
internally on top of 'next' from 46 to 29. :) (All but 7 of those are
the rest of config-based-hooks.)

Good to hear, I'm waiting on Junio to merge this down, and will then
submit the next step in the config-based hook conversion.

It might seem slightly selfish for me to include config-based-hooks in
the "submodules update" letter, but this is actually very important for
submodules too - without config-based hooks, we don't have a good way to
distribute a hook across an entire Git superproject-and-submodules
codebase. With config-based hooks + "config.superproject" shared between
the submodules and superproject, this becomes a very easy story :)

I'm probably missing something, not that config-based hooks aren't great
& all that, but for this specific use-case wouldn't core.hooksPath work?
I.e. to simply set that in the submodules to the superproject's
.git/hooks directory?

That could even be done with the includeIf + include.path mechanism to
apply to all projects below a certain path, which presumably is similar
to how it would work with config-based hooks.

Obviously the full config-based hook mechanism is much nicer, I just
wonder if it's something you can use as a transitory mechanism until
then.