On Sat, Jul 10, 2021 at 11:03:50AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>
> 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.
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
