Re: [PATCH 1/1] builtin/receive-pack: avoid spinning no-op sideband async threads

From: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Mar 3, 2026, 12:45 UTC
Message-ID: <875x7dozdd.fsf@gentoo.mail-host-address-is-not-set>
In-Reply-To: <aaZ7eXtUSWSS_igX@pks.im>

On Tue, 03 Mar 2026, Patrick Steinhardt <ps@pks.im> wrote:

Show 11 quoted lines

> On Mon, Mar 02, 2026 at 09:17:04PM +0200, Adrian Ratiu wrote:
>> Exit early if the hooks do not exist, to avoid spinning up/down
>> sideband async threads which no-op.
>> 
>> It is important to call the hook_exists() API provided by hook.[ch]
>> because it covers both config-defined hooks and the "traditional"
>> hooks from the hookdir. find_hook() only covers the hookdir hooks.
>
> Just out of curiosity: will `find_hook()` eventually be removed? I saw
> that we still use it for the "proc-receive" hook in git-receive-pack(1)
> for example, which feels a bit fishy to me.

The answer is a big YES and I actually thought about this while fixing the regression yesterday (unrelated to proc-receive).

All hooks should use the new hook.[ch] APIs which provide clearer functions like hook_exists() and all direct find_hook() / run-command invocations should be removed.

> In any case, if this is an oversight then this can be handled in a
> subsequent patch series, if you ask me.

Yes, this can be done incrementally in a subsequent patch so that proc-receive can also benefit from hook.[ch] features like being able to specify it via configs.

It was out of scope for the initial patches, so I didn't pay too much attention to it, but it should be rather simple to convert. I do plan to convert it as well.

The end goal is to make find_hook() static (not exported outside hook.c) once all its external uses have been converted.