From: Adrian Ratiu Date: Thu, 22 Jan 2026 09:26:14 GMT Subject: Re: [PATCH v7 11/12] receive-pack: convert update hooks to new API Message-ID: <87cy32q9qh.fsf@collabora.com> In-Reply-To: <376ae697-efcf-41f9-b92d-e62ca12a77a2@app.fastmail.com> On Wed, 21 Jan 2026, "Kristoffer Haugsbakk" 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 > > 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!