On Tue, Jan 25 2022, Emily Shaffer wrote:
>> * 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: <cover-v6-00.17-00000000000-20211222T035755Z-avarab@xxxxxxxxx>
>>
>
> 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.
