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

From: Emily Shaffer <emilyshaffer@google.com>
Date: Apr 15, 2020, 22:48 UTC
Message-ID: <20200415224852.GC24777@google.com>
In-Reply-To: <20200415224244.GB3595509@coredump.intra.peff.net>

On Wed, Apr 15, 2020 at 06:42:44PM -0400, Jeff King wrote:

Show 18 quoted lines

> 
> 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