Re: [PATCH v3 5/9] hook: mark non-parallelizable hooks

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2026, 20:56 UTC
Message-ID: <xmqqcy14stf7.fsf@gitster.g>
In-Reply-To: <20260309133739.294555-6-adrian.ratiu@collabora.com>

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

Show 7 quoted lines

>  hook.jobs::
>  	Specifies how many hooks can be run simultaneously during parallelized
>  	hook execution. If unspecified, defaults to 1 (serial execution).
> +	Some hooks always run sequentially regardless of this setting because
> +	git knows they cannot safely be parallelized: `applypatch-msg`,
> +	`pre-commit`, `prepare-commit-msg`, `commit-msg`, `post-commit`,
> +	`post-checkout`, and `push-to-checkout`.

If there is a simple rule that can be used to decide hooks with what characteristics can and cannot be run in parallel, near the "because git knows" sentence is where we want to write it down. It would help new developers decide if their newly invented hook should be forced serial execution.

For example, applypatch-msg is given a file and is allowed to modify the file (perhaps reformat or typofix), so two of them competing to edit that single file would be a nonsense. Letting them edit the file one after the other would make much more sense. So one of the rules may be "a hook that is given a file and expected to edit it". other two hooks with -msg suffix may fall into the same category. What are the rules behind the decision for others? Are they also explained with simple rules?