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

[Junio C Hamano <gitster@pobox.com>]

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?

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.