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

[Jeff King <peff@peff.net>]

On Tue, Apr 07, 2020 at 04:51:16PM -0700, Emily Shaffer wrote:

> On Tue, Apr 07, 2020 at 04:01:32PM -0700, Emily Shaffer wrote:
> > Thoughts?
> 
> Jonathan Nieder and I discussed this a little bit offline, and he
> suggested another thought:
> 
> [hook "unique-name"]
>   pre-commit = ~/path-to-hook.sh args-for-precommit
>   pre-push = ~/path-to-hook.sh
>   order = 001

Yeah, giving each block a unique name lets you give them each an order.
It seems kind of weird to me that you'd define multiple hook types for a
given name. 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).

What if we added a layer of indirection: have a section for each type of
hook, defining keys for that type. And then for each hook command we
define there, it can have its own section, too. Maybe better explained
with an example:

  [hook "pre-receive"]
  # put any pre-receive related options here; e.g., a rule for what to
  # do with hook exit codes (e.g., stop running, run all but return exit
  # code, ignore failures, etc)
  fail = stop

  # And we can define actual hook commands. This one refers to the
  # hookcmd block below.
  command = foo

  # But if there's no such hookcmd block, we could just do something
  # sensible, like defaulting hookcmd.X.command to "X"
  command = /path/to/some-hook.sh

  [hookcmd "foo"]
  # the actual hook command to run
  command = /path/to/another-hook
  # other hook options, like order priority
  order = 123

I think both this schema and the one you wrote above can express the
same set of things. But you don't _have_ to pick a unique name if you
don't want to. Just doing:

  [hook "pre-receive"]
  command = /some/script

would be valid and useful (and that's as far as 99% of use cases would
need to go).

-Peff