Re: Submodule UX overhaul update (was: What's cooking in git.git (Jan 2022, #07; Mon, 24))
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jan 26, 2022, 14:09 UTC
- Message-ID
- <220126.867damfuvo.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <YfBTRuPrGGjepe+D@google.com>
On Tue, Jan 25 2022, Emily Shaffer wrote:
Show 30 quoted lines
>> * 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.
Show 6 quoted lines
> 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.