On Fri, Jul 09 2021, Emily Shaffer wrote:
> 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.
