Re: [PATCH v2] hook: introduce the report hook for git-receive-pack(1)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 21, 2026, 16:55 UTC
- Message-ID
- <xmqqy0dzpg4z.fsf@gitster.g>
- In-Reply-To
- <aohXatWhxCAUQTcq@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 18 quoted lines
> On Fri, Aug 21, 2026 at 03:34:58PM +0200, Karthik Nayak wrote: > [snip] >> - Exit 0: the hook's stdout is used as the report. The hook can >> rewrite 'ok' lines to 'ng' lines to signal per-ref rejection to the >> client while receive-pack itself exits cleanly. The client marks >> rejected refs as '[remote rejected]' and exits with a non-zero >> status if any ref is 'ng'. >> >> - Non-zero exit: the hook's stdout is discarded, receive-pack calls >> die(), and no report is sent to the client at all. The client >> observes a sideband disconnect and reports 'the remote end hung up >> unexpectedly', treating the entire push as failed. > > I was thinking about this case a bit more. Should we maybe handle it > similarly to the pre-receive hook instead of dieing? If that hook fails > we basically update all references to "pre-receive hook declined", > whereas we could update all of them to "report hook failed". That might > make for a better user experience.
It is a bit different in that pre-receive is all-or-nothing, but I agree that it makes sense to model a failure case after how it works. In general, it helps to explicitly tell the other end that their action was declined than let them assume that no news is a bad news.
I also agree with other points in your review, but I consider the above is the most valuable input ;-).
Thanks.