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

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Mar 18, 2026, 18:40 UTC
Message-ID: <87y0jp0ymp.fsf@collabora.com>
In-Reply-To: <xmqqcy14stf7.fsf@gitster.g>

On Sun, 15 Mar 2026, Junio C Hamano <gitster@pobox.com> wrote:

Show 24 quoted lines

> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>
>>  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?

The simplest and highest level rule I can think of is that these hooks operate on shared data, so they cannot be safely parallelized.

I'll make this rule clearer in the re-roll.

For the *-msg hooks, as you mentioned, it's a file. For *-commit and *-checkout hooks, it's the worktree or index.

post-commit is a bit special because it typically invokes git commands that contend on lock files. Happy to drop this from the list if I've been too conservative on it (it's a 1 liner change + this doc) and allow it to be parallelized.

Suggestions are welcome, as always.