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
