From: Adrian Ratiu Date: Wed, 18 Mar 2026 18:40:46 GMT Subject: Re: [PATCH v3 5/9] hook: mark non-parallelizable hooks Message-ID: <87y0jp0ymp.fsf@collabora.com> In-Reply-To: On Sun, 15 Mar 2026, Junio C Hamano wrote: > Adrian Ratiu 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.