From: Adrian Ratiu Date: Fri, 13 Feb 2026 17:21:02 GMT Subject: Re: [PATCH 0/4] Run hooks in parallel Message-ID: <87h5rkpnk1.fsf@collabora.com> In-Reply-To: <1dd09e04-dbdb-4a6c-933a-e4dc451878f9@gmail.com> On Fri, 13 Feb 2026, Phillip Wood wrote: >>>> 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? >> >> Thank you for raising this, it is a very valuable data point! >> >> The preparatory series 100% will not reintroduce it. >> >> This series might reintroduce it, depending how we set the defaults. >> >> By that I mean: >> -j1 will keep all hooks connected to the tty, just like before. >> -jN with N>1 will disconnect the hooks from the tty and their >> outputs will get buffered through run-command's pipes. >> >> The design I followed (which to be transparent is Peff's design, I just >> implemented his ideas :), is the keep the original, serialized behavior >> exactly how it was before, to not introduce any regressions and to also >> keep identical "real-time" performance. >> >> Taking this into account, together with Patrick's feedback on this >> series, I do intend keep the jobs == 1 default for all hooks in v2. > > I think that would be safer. If we could opt-in to parallel execution on > a per-hook basis would that be a solution for the "pre-push" hook? Users > who want to keep the current behavior would avoid configuring parallel > execution for that hook. Yes, opting in on a per-hook basis is one of the mechanisms I'll be adding in v2 (that's what I've been discussing with Patrick via the other thread on this series). However we also need a mechanism to enable more than just 1 hook at a time, for users who want to enable by default a known-good set of hooks to run in parallel. That's what we did with `RUN_HOOKS_OPT_INIT_PARALLEL` at compile-time in v1, however that's a dead end and I won't pursue it. For v2 I'm thinking of a runtime/global config which can specify a list of hook to default for parallel execution. That should be enough to replace RUN_HOOKS_OPT_INIT_PARALLEL. Suggestions welcome, as always. :)