Re: Submodule UX overhaul update (was: What's cooking in git.git (Jan 2022, #07; Mon, 24))

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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@gmail.com>
>> 
>
> 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.