Re: [PATCH 0/4] Run hooks in parallel

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Fri, 13 Feb 2026, Phillip Wood <phillip.wood123@gmail.com> wrote:
<snip>
>>>> 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. :)