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

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Feb 26, 2026, 12:21 UTC
Message-ID: <87cy1rbspp.fsf@gentoo.mail-host-address-is-not-set>
In-Reply-To: <xmqqzf4wacuh.fsf@gitster.g>

On Wed, 25 Feb 2026, Junio C Hamano <gitster@pobox.com> wrote:

Show 44 quoted lines

> Adrian Ratiu <adrian.ratiu@collabora.com> writes:
>
>> On Sat, 21 Feb 2026, Adrian Ratiu <adrian.ratiu@collabora.com> wrote:
>>> 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.
>>>>
>>>> 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). :) 
>>> ...
>>>
>> Hi again Brian,
>>
>> v2 of the parallel series is out if you want to review it:
>>
>> https://lore.kernel.org/git/20260222002904.1879356-1-adrian.ratiu@collabora.com/T/#u
>>
>> P.S. I think your spam filter is blocking all my e-mails? I get this
>> reply from you:
>>
>>  sandals@crustytoothpaste.net, ERROR CODE :554 - 5.7.1
>>  <sender4-op-o12.zoho.com[136.143.188.12]>: Client host rejected:
>>  CONN:SPAM
>>
>>    Original-Recipient: rfc822; sandals@crustytoothpaste.net
>>    Final-Recipient: rfc822; sandals@crustytoothpaste.net
>>    Status: 554
>>    Action: failed
>>    Last-Attempt-Date: 22 Feb 2026 00:30:10 GMT
>>    Diagnostic-Code: 5.7.1 <sender4-op-o12.zoho.com[136.143.188.12]>: Client host rejected: CONN:SPAM
>>    Remote-MTA: dns; complex.crustytoothpaste.net
>
> So, shall we make this "hooks specified by config" advance, while
> expecting the parallelized execution to further evolve as a follow
> up series that will still be out of 'next' for now?

Yes, that is correct.

These are independent patch series which just happen to depend one upon the other. Other than that, they are completely separate and should be reviewed independently, each on its own merits.

(When you have some time please review v2 of the parallel series.)

I do plan to send v3 of this config series, then v3 of the parallel series after it gathers feedback.

They do not need to evolve in tandem, btw.

We can even put the parallel series "on pause" until this config series is done and lands, if it makes things easier.

Thanks, Adrian