On 2024-03-15 at 00:04:25, Chris Torek wrote: > On Thu, Mar 14, 2024 at 4:37 PM Junio C Hamano <gitster@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
