Subject: Re: [PATCH v7 11/12] receive-pack: convert update hooks to new API

From: Adrian Ratiu <[email-masked]>
Date: Thu, 22 Jan 2026 11:26:14 +0200

On Wed, 21 Jan 2026, "Kristoffer Haugsbakk" <[email-masked]> wrote:
> On Wed, Jan 21, 2026, at 22:54, Adrian Ratiu wrote:
>> The hook API avoids creating a custom struct child_process and other
>> internal hook plumbing (e.g. calling find_hook()) and prepares for
>> the specification of hooks via configs or running parallel hooks.
>>
>> Execution is still sequential through the run_hooks_opt .jobs == 1,
>> which is the unchanged default for all hooks.
>>
>> When jobs==1 the async muxer thread reads the hook stderr and writes
>> to sideband 2, so run-command's poll loop is avoided and there's no
>> need for ungroup=0 when running sequentially (Jeff's suggestion).
>>
>> When running in parallel, run-command with ungroup=0 will capture
>> and de-interleave the output of each hook, then write to the parent
>> stderr which is redirected via dup2 to the sideband muxer, so that
>> parallel hook output is presented clearly to the client.
>>
>> Suggested-by: Jeff King <[email-masked]>
>
> I don’t understand why the new (in this round) trailer is here. Wouldn’t
> it be better to put it before your signoff? Now it looks like Peff
> suggested something and then Emily and Ævar signed off later.
>
> And I don’t know but `Helped-by` is often useful here. This is an old
> patch that he improved. To me “suggested” suggests that he proposed the
> idea for the patch or something.

Indeed a "Helped-by" before my sign-off seems the better fit here.

While at it, I also noticed I accidentaly reset the authorship on this
and another patch when reworking on top of the new design suggested by
Peff.

Will fix in v8. Thanks!