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

From: Adrian Ratiu <[email-masked]>
Date: Wed, 18 Mar 2026 20:40:46 +0200

On Sun, 15 Mar 2026, Junio C Hamano <[email-masked]> wrote:
> Adrian Ratiu <[email-masked]> 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.