From: Adrian Ratiu <adrian.ratiu@collabora•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>,
Emily Shaffer <emilyshaffer@google•com>,
Jeff King <peff@peff•net>
Subject: Re: [PATCH 1/1] builtin/receive-pack: avoid spinning no-op sideband async threads
Date: Tue, 03 Mar 2026 14:45:34 +0200 [thread overview]
Message-ID: <875x7dozdd.fsf@gentoo.mail-host-address-is-not-set> (raw)
In-Reply-To: <aaZ7eXtUSWSS_igX@pks.im>
On Tue, 03 Mar 2026, Patrick Steinhardt <ps@pks•im> 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.
next prev parent reply other threads:[~2026-03-03 12:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 19:17 [PATCH 0/1] Fix update hook perf regression in next Adrian Ratiu
2026-03-02 19:17 ` [PATCH 1/1] builtin/receive-pack: avoid spinning no-op sideband async threads Adrian Ratiu
2026-03-02 21:40 ` Junio C Hamano
2026-03-03 12:47 ` Adrian Ratiu
2026-03-03 6:11 ` Patrick Steinhardt
2026-03-03 12:45 ` Adrian Ratiu [this message]
2026-03-03 13:28 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875x7dozdd.fsf@gentoo.mail-host-address-is-not-set \
--to=adrian.ratiu@collabora$(echo .)com \
--cc=emilyshaffer@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox