From: Adrian Ratiu Date: Wed, 18 Mar 2026 19:21:49 GMT Subject: Re: [PATCH v3 7/9] hook: add per-event jobs config Message-ID: <87se9x0wqa.fsf@collabora.com> In-Reply-To: On Mon, 16 Mar 2026, Junio C Hamano wrote: > Adrian Ratiu writes: > >> +hook..jobs:: >> + Specifies how many hooks can be run simultaneously for the `` >> + hook event (e.g. `hook.post-receive.jobs = 4`). Overrides `hook.jobs` >> + for this specific event. The same parallelism restrictions apply: this >> + setting has no effect unless all configured hooks for the event have >> + `hook..parallel` set to `true`. Must be a positive int, >> + zero is rejected with a warning. See linkgit:git-hook[1]. >> ++ >> +Note on naming: although this key resembles `hook..*` >> +(a per-hook setting), `` must be the event name, not a hook >> +friendly name. The key component is stored literally and looked up by >> +event name at runtime with no translation between the two namespaces. >> +A key like `hook.my-hook.jobs` is stored under `"my-hook"` but the >> +lookup at runtime uses the event name (e.g. `"post-receive"`), so >> +`hook.my-hook.jobs` is silently ignored even when `my-hook` is >> +registered for that event. Use `hook.post-receive.jobs` or any other >> +valid event name when setting `hook..jobs`. > > This design is unfortunate but cannot be avoided, as we do not want > two hooks (i.e., two different names) that react to a single event > specify .jobs value differently. Naturally, we need to worry about > what happens when somebody gives the name "foo" to their hook that > reacts to "foo" event, but that would probably be benign if there is > no other hook that reacts to "foo" event. I also wonder if we want > to sanity check and complain upon seeing hook.foo.jobs set when > "foo" is not a known event type. > > Perhaps anything that appears with one of the .command, .event, or > .parallel are likely to be , so having .jobs under > such configuration key is safe to flag as a mistake, or something? I think this is reasonable, yes, and it helps avoid confusion between per-hook friendly-names and per-event "name" values. Will do in the re-roll. > > A careful reader who is reading this message from the sideline may > notice that I specifically omitted .enabled from the above "clues > for friendly-name key". I think hook..enabled that acts as a > master switch to prevents all hooks from firing for a particular > event (when set to 'false') may be something people eventually want, > in addition to per-hook command hook..enabled switch > that can override it (or do we want to forbid overriding it? I > dunno).. I think this is reasonable as well. Having a higher-level switch for all hooks in an event should be useful, in addition to the already implemented lower-level per-hook "friendly-name" enabled key. I can add a new commit for this in the re-roll.