Subject: Re: [TOPIC 2/17] Hooks in the future

From: Emily Shaffer <[email-masked]>
Date: Wed, 15 Apr 2020 15:48:52 -0700

On Wed, Apr 15, 2020 at 06:42:44PM -0400, Jeff King wrote:
> 
> On Tue, Apr 14, 2020 at 08:45:50PM -0700, Jonathan Nieder wrote:
> > >>> And it doesn't leave a lot of room for defining
> > >>> per-hook-type options; you have to make new keys like pre-push-order
> > >>> (though that does work because the hook names are a finite set that
> > >>> conforms to our config key names).
> > 
> > Exactly: field names like prePushOrder should work okay, even if
> > they're a bit noisy.
> 
> A side note:
> 
> Here you've done a custom munging of pre-push into prePush. I'm fine
> with that, but would we ever want to allow third-party scripts to define
> their own hooks using this mechanism? E.g., if there's a git-hooks
> command could I run "git hooks run foo" to run the foo hook? If so, then
> it might be simpler to just use the name as-is rather than defining the
> exact munging rules.

I did envision that kind of thing, or at very least something like
`git hook --list --porcelain foo | xargs -n 1 sh -c`. When I saw
Jonathan's suggestion I wondered if using the hookname as is (pre-push)
was not idiomatic to the config, and maybe I should change it. But I
would rather leave it identical to the hookname, personally.

 - Emily