Re: [PATCH v3 7/9] hook: add per-event jobs config

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Mon, 16 Mar 2026, Junio C Hamano <gitster@pobox.com> wrote:
> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>
>> +hook.<event>.jobs::
>> +	Specifies how many hooks can be run simultaneously for the `<event>`
>> +	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.<friendly-name>.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.<friendly-name>.*`
>> +(a per-hook setting), `<event>` 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.<event>.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 <friendly-name>, 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.<event>.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.<friendly-name>.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.