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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 10, 2021, 09:03 UTC
Message-ID: <87wnpy4jyb.fsf@evledraar.gmail.com>
In-Reply-To: <YOixxZQDVDKIM8bo@google.com>

On Fri, Jul 09 2021, Emily Shaffer wrote:

Show 18 quoted lines

> On Tue, Jun 29, 2021 at 08:54:02PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>  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.