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
