Re: [PATCH 0/2] Optionally support push options on up-to-date branches

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Mar 15, 2024, 00:57 UTC
Message-ID: <ZfOc9hrayymnJNPc@tapette.crustytoothpaste.net>
In-Reply-To: <CAPx1Gvez4Ema9Yi-7Ei8OOkq9t8AXmBYN=yy948k_C+ZBKdXmw@mail.gmail.com>

On 2024-03-15 at 00:04:25, Chris Torek wrote:

Show 17 quoted lines

> On Thu, Mar 14, 2024 at 4:37 PM Junio C Hamano <gitster@pobox.com> wrote:
> > In any case, I am OK with the feature.  I just was wondering if the
> > end-user experience may become simpler and easier if we did not have
> > to have a command line option.
> 
> Would it make sense for the *server* to request the option?
> 
> That is, you run:
> 
>     git push server-remote ref
> 
> and if the server at server-remote "wants" to know about "no-op
> pushes" because it will do something for this case, it says so.
> If the server says nothing, the client doesn't bother with the no-op
> pushes.
> 
> (This could be either per-ref or global, too.)

This is an interesting idea. I don't think this can be per-ref because at the capabilities stage, we don't actually know what the user wants to send, if anything. v0 capabilities are too limited in size to declare per-ref options, although I suppose v2 could, in theory, support that.

I do worry, though, that even if the server may be interested in additional push options or push certificates, as Chris's series indicates, it may not generally care about no-op ref updates, and thus, it may not be granular enough to avoid the kinds of performance problems that I've mentioned elsewhere in the thread.

For example, I know that GitLab uses push options (and GitHub has support for them as well in some cases) and thus the proposed feature would be useful there, but I suspect we'd still want regular no-op pushes (without push options or push certificates) to not be sent for performance reasons.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA