Re: [PATCH v2 3/3] hook-list.h: add a generated list of hooks, like config-list.h

On Sat, Jul 10, 2021 at 11:03:50AM +0200, Ævar Arnfjörð Bjarmason wrote:

On Fri, Jul 09 2021, Emily Shaffer wrote:

quoted

On Tue, Jun 29, 2021 at 08:54:02PM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

 const char *find_hook(const char *name)
 {
 	static struct strbuf path = STRBUF_INIT;
 
+	if (!known_hook(name))
+		die(_("the hook '%s' is not known to git, should be in hook-list.h via githooks(5)"),
+		    name);
+

I'm not sure that it's necessary to require this, to be honest. I see a
use case for wrappers to want to store and run hooks in an idiomatic
way, and doing so by instructing their users to stick in
.git/hooks/wrapper-clone (for example) and then calling 'git hook run
wrapper-clone'. That's doubly compelling in a later config-based-hooks
world where 'git hook run' gets you free multihook features like
ordering and parallelism. I will likely want to remove this when
rebasing my config-based hooks work on top of your restart.

Indeed, FWIW this was part of my general approach of narrowly supporting
existing git behavior only with 'git hook run', i.e. there's no general
"run this thing like a hook for me" now, so we're not losing anything by
not having it support that.

But yes, I can see how "run this script for me as if though it were a
hook" would be useful, will be trivial to support it & still somehow
assert typos/that hook-list.h / githooks.txt is a source of truth about
our known hooks.

Hm, I see - you're using the BUG() to gently remind people that they
should go and update githooks.txt if they call find_hook("new-hook").
Ok, I'll add a flag or a wrapper or something in my own rebase - so 'git
hook run' doesn't check but internal calls do.

Thanks for explaining the intent better.
 - Emily