Re: [PATCH] hook: introduce the report hook for git-receive-pack(1)

Karthik Nayak <[email protected]> Wed, 19 Aug 2026 15:24:21 +0200
Newsgroups	org.kernel.vger.git
Message-ID	<CAOLa=ZSuzd3FozharJ_1LRgaQdpY+eRZnMOJYoLJNvPXiait1w@mail.gmail.com>
Patrick Steinhardt <[email protected]> writes:

> On Wed, Aug 19, 2026 at 03:13:50PM +0200, Karthik Nayak wrote:
>> Patrick Steinhardt <[email protected]> writes:
>>
>> > On Tue, Aug 18, 2026 at 09:55:55AM +0200, Karthik Nayak wrote:
>> >> When running 'git-receive-pack(1)', there is currently no way for the
>> >> server to intercept and modify the status report before it is sent back
>> >> to the client. This is useful for servers with custom logic that need
>> >> to transform or gate the report based on the outcome of external logic
>> >> post reference updates.
>> >>
>> >> Introduce a new 'report' hook which receives the pkt-line encoded
>> >> status report on stdin and whose stdout replaces the report sent to the
>> >> client. A non-zero exit status causes `receive-pack` to die and the
>> >> client to treat the push as failed.
>> >
>> > I think it would have been useful to add context why none of the
>> > preexisting hooks work for us:
>> >
>> >   - The pre-receive hook runs too early, as we haven't updated
>> >     references at that point yet and we need to have the full view of
>> >     all resulting updates (both objects and references).
>> >
>> >   - The update hook is too inefficient as it runs once per reference,
>> >     and we cannot trivially determine the last update.
>> >
>> >   - The reference-transaction hook cannot be used by us because we care
>> >     about the phase where it was committed already. And while the hook
>> >     fires in that phase, it does not allow the caller to modify the
>> >     result in any capacity.
>> >
>> >   - The post-receive and post-update hooks cannot be used as they run
>> >     too late, at the point where we have already reported success to the
>> >     client.
>> >
>>
>> Yeah, this is worthwhile mentioning, I already have made the commit
>> message a lot more descriptive, so it does become bloated. I think it is
>> justified though, since more information is always more useful than less.
>
> Well. Until it isn't anymore :) Just look at the walls of text that AI
> is prone to generate, where one is essentially drowning in information.
> And it's the worst kind of information, too: plausibly looking but
> inherently dubious.
>
> Anyway, I digress. I think in this context it's good to have the context
> indeed, and I trust your information more than the one generated by AI.
>

I have been using AI to correct my grammar :D

Point taken, I'll try to find a balance.

>> >> diff --git a/Documentation/githooks.adoc b/Documentation/githooks.adoc
>> >> index ed045940d1..7e6643ad89 100644
>> >> --- a/Documentation/githooks.adoc
>> >> +++ b/Documentation/githooks.adoc
>> >> @@ -527,6 +527,29 @@ The exit status of the hook is ignored for any state except for the
>> >> To reject individual ref updates, rewrite the corresponding
>> >> +`ok` lines to `ng` lines in the output report (with an explanatory
>> >> +error string) and exit zero; standard error can accompany this to
>> >> +provide a human-readable explanation. A non-zero exit status causes
>> >> +`receive-pack` to die.
>> >
>> > We should probably document that we expect the hook to never return
>> > non-zero, even if it rejects reference updates, and that doing so
>> > indicates a bug. This is mostly because git-receive-pack(1) shouldn't
>> > ever just die on the client without giving it a proper status.
>> >
>>
>> Yeah, this is a part I was thinking about but wasn't sure if it should
>> be added in because, we could also do an implementation where we simply
>> ignore the exit code of the hook.
>
> There could be cases where just making the whole operation explode is
> the only remaining option. So I don't think it's necessarily bad to have
> it as the nuclear option.
>
> Patrick

Okay let's settle on that.
signature.asc (application/pgp-signature, 690 B)