Re: [PATCH 0/4] Run hooks in parallel
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Feb 12, 2026, 10:43 UTC
- Message-ID
- <eedde9c3-2aff-433b-9dc3-f8593d53dec0@gmail.com>
- In-Reply-To
- <20260204173328.1601807-1-adrian.ratiu@collabora.com>
Hi Adrian
On 04/02/2026 17:33, Adrian Ratiu wrote:
Show 18 quoted lines
> Hello everyone, > > This enables running hook commands in parallel and is based on the patch > series enabling config hooks [1], which added the ability to run a list > of hooks for each hook event. > > For context, hooks used to run sequentially due to hardcoded .jobs == 1 > in hook.c, leading to .processes == 1 in run-command.c. We're removing > that restriction for hooks known to be safe to parallelize. > > The parallelism enabled here is to run multiple hook commands/scripts > in parallel for a single event, for example the pre-push event might > trigger linters / spell checkers / unit tests to run at the same time. > > Another kind of parallelism is to split the hook input to multiple > child processes, running the same command in parallel on subsets of > the hook input. This series does not do that. It might be a future > addition on top of this, since it's kind of a lower-level parallelism.
There's quite a lot of prior-art on parallelization from the various hook managers - is there anything we can learn from them? For example I know some of them serialize the pre-commit hook by default as it may update the index but allow the user to configure a subset of scripts that can be parallelized. They also allow for parallelization where different scripts update different files (e.g. code formatters for python and C can run in parallel). We don't need to implement all that now but we should design our config so that we can support it in the future.
> The pre-push hook is special because it is the only known hook to break > backward compatibility when running in parallel, due to run-command > collating its outputs via a pipe, so I added an extension for it. > Users can opt-in to this extension with a runtime config.
In the past we had a regression report [1] when the pre-commit hook stopped having access to the terminal. I've not been following the hook changes, is this series (or any of your preparatory series) in danger of reintroducing that regression?
Thanks for working on this - both config based hooks and parallel execution are really nice improvements.
Phillip
[1] https://lore.kernel.org/git/xmqqr15rr9k6.fsf@gitster.g/
Show 52 quoted lines
> Suggestions for alternative solutions to the extension are welcome. > > Again, this is based on the latest v1 config hooks series [1] which > has not yet landed in next or master. > > Branch pushed to GitHub containing all dependency patches: [2] > Successful CI run: [3] > > Many thanks to all who contributed to this effort up to now, including > Emily, AEvar, Junio, Patrick, Peff and many others. > > Thank you, > Adrian > > 1: https://lore.kernel.org/git/20260204165126.1548805-1-adrian.ratiu@collabora.com/T/#mdb138a39d332f234bc9068b7f4e05b10c400e572 > 2: https://github.com/10ne1/git/tree/refs/heads/dev/aratiu/parallel-hooks-v1 > 3: https://github.com/10ne1/git/actions/runs/21680184456 > > Adrian Ratiu (3): > config: add a repo_config_get_uint() helper > hook: introduce extensions.hookStdoutToStderr > hook: allow runtime enabling extensions.hookStdoutToStderr > > Emily Shaffer (1): > hook: allow parallel hook execution > > Documentation/config/extensions.adoc | 15 ++ > Documentation/config/hook.adoc | 14 ++ > Documentation/git-hook.adoc | 14 +- > builtin/am.c | 10 +- > builtin/checkout.c | 13 +- > builtin/clone.c | 6 +- > builtin/hook.c | 7 +- > builtin/receive-pack.c | 9 +- > builtin/worktree.c | 2 +- > commit.c | 2 +- > config.c | 28 +++ > config.h | 13 ++ > hook.c | 51 ++++- > hook.h | 20 +- > parse.c | 9 + > parse.h | 1 + > refs.c | 2 +- > repository.c | 1 + > repository.h | 1 + > sequencer.c | 4 +- > setup.c | 17 ++ > setup.h | 1 + > t/t1800-hook.sh | 270 ++++++++++++++++++++++++++- > transport.c | 9 +- > 24 files changed, 476 insertions(+), 43 deletions(-) >