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

>>>> 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.