Re: [PATCH v2 0/8] Specify hooks via configs

> On Fri, 20 Feb 2026, "brian m. carlson" <sandals@crustytoothpaste.net> wrote:
>> On 2026-02-18 at 22:23:44, Adrian Ratiu wrote:
>>> Hello everyone,
>>> 
>>> v2 addresses all feedback received in v1.
>>> 
>>> This series adds a new feature: the ability to specify commands to run
>>> for hook events via config entries (including shell commands).
>>> 
>>> So instead of dropping a shell script or a custom program in .git/hooks
>>> you can now tell git via config files to run a program or shell script
>>> (can be specified directly in the config) when you run hook "foo".
>>> 
>>> This also means you can setup global hooks to run in multiple repos via
>>> global configs and there's an option to disable them if necessary.
>>> 
>>> For simplicity, because this series is becoming rather big, hooks are
>>> still executed sequentially (.jobs == 1). Parallel execution is added
>>> in another patch series.
>>
>> I'm interested in how you plan to make parallel execution work
>> gracefully.
>>
>> We've already established that it's necessary to preserve stdout and
>> stderr (including wiring them up to the TTY) so as to not break
>> existing, widely deployed hooks, such as those in Git LFS.  That means
>> that to get parallel execution where the hooks don't write over each
>> other's output and fight for the terminal, you'd need to multiplex each
>> one, including providing a PTY if the appropriate descriptor already has
>> a terminal, such that the output is at the very least handled line by
>> line and ideally batched into per-hook chunks.  Is that the plan, or do
>> you plan to do it differently?
>>
>> I ask because situations where the hook output is not handled gracefully
>> and hooks fight over output or where the existence of TTY on a file
>> descriptor is not preserved will result in bug reports and broken tests
>> for tools that use Git, which I think we'd all like to avoid.
>
> Hi Brian,
>
> Yes, this is all done already. Phillip Wood actually brought this TTY
> issue up in his review of the v1 parallel hooks series (many thanks). :) 
>
>
>> Of course, that's not in this series, so it may not even be written yet,
>> but if it's not, then this is something to keep in mind for when it gets
>> submitted.
>
> Yes, that's a separate series [1] and I'm about to send v2 very soon.
>
> Please review v2 directly when I send it because it will contain
> significant changes from v1. v1 is not worth reviewing at this point.
>
> To give you a high level description:
>
> All hooks continue to run sequentially (serialized) by default, just
> like before.
>
> To run some of the hooks in parallel, I had to introduce an extension,
> because we need to break backwards compatibility by combining stdout and
> stderr and piping them through run-command's muxer, detached from the
> terminal. There is only 1 known hook requiring this extension (pre-push)
> but it's trivial to add more, if necessary.
>
> Patrick's idea is to leave it up to the user to decide what to
> parallelize, because the user knows if their hooks are safe or not (eg 
> if they write the same file or call the same program), or if it's ok the
> enable the extension or not.
>
> Some hooks are known never to be safe to parallelize, in that case git
> will always enforce serial execution.
>
> Please wait for v2 of that series, it's my top priority to get it out,
> Adrian
>
> 1:
> https://lore.kernel.org/git/20260204173328.1601807-1-adrian.ratiu@collabora.com/n