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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 16, 2026, 18:40 UTC
Message-ID: <xmqq341zpqhv.fsf@gitster.g>
In-Reply-To: <20260309133739.294555-8-adrian.ratiu@collabora.com>

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

Show 17 quoted lines

> +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?

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)..

Other than that, looking quite well done.

Thanks.