From: Adrian Ratiu Date: Tue, 03 Mar 2026 12:45:34 GMT Subject: Re: [PATCH 1/1] builtin/receive-pack: avoid spinning no-op sideband async threads Message-ID: <875x7dozdd.fsf@gentoo.mail-host-address-is-not-set> In-Reply-To: On Tue, 03 Mar 2026, Patrick Steinhardt wrote: > 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.