Re: [PATCH v4 05/11] transport: convert pre-push to hook API

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 17, 2025, 23:07 UTC
Message-ID: <xmqqecos1zct.fsf@gitster.g>
In-Reply-To: <aUEmtv09kkEZ2cJ4@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 18 quoted lines

> On Tue, Dec 16, 2025 at 11:09:52AM +0200, Adrian Ratiu wrote:
> ...
>> The reason is the list was not exhaustive: for refs which we know
>> beforehand will not be pushed (status rejected), there is no need to
>> feed the pre-push hook stdin. It's saving a few cpu cycles in some
>> rejection corner cases, which were missed previously.
>> 
>> I could:
>> 1. Split the extra *_REJECT_* case aditions into a separate commit,
>>    highlighting and explaining this better.
>> 2. Drop the new cases since they are just a minor improvement in this
>>    series, not very important for the series overall.
>> 
>> Any preference?
>
> I'd personally learn towards (2) unless it is fixing an actual bug that
> can be demonstrated. In that case it might make sense to do (1) and
> explain why this wasn't an issue until now.

I tend to agree. If my hook did something depending on the branches the pusher is _trying_ to update, not doing (2) would even be a regression.

If "git push there next seen" attempts to push these two, we know seen does not fast-forward and locally decide to refrain from pushing it, it would silently turn into "git push there next", but the hook may want to behave differently between these two sets of command line arguments.

Thanks.