On Wed, Jan 26, 2022 at 03:09:19PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>
> 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.
Thanks!
>
> > 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.
It's not quite so simple. We could set core.hooksPath in /etc/gitconfig,
but a user who already has core.hooksPath set in ~/.gitconfig would
override it. And since we're currently working with users who previously
used Repo, it wouldn't surprise me to see savvy users globally setting
core.hooksPath because that doesn't interfere with Repo's own hook
system. In that case, even using an includeIf around the /etc/gitconfig
line won't help, because I'd guess the config included at the system
level will still be overridden by the config included at the global
level.
And anyway.... we've been shipping config based hooks internally for
over a year now, so there's not much reason to stop now ;)
>
> 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.
>
- Emily
