Thanks for the reply. Would you be able to point me to some breadcrumbs for the "required protocol messages"? I might try to tinker in some spare time. FWIW, I had put something like this together a while back using Gitolite hosting (a dedicated SSH command similar to Gitolite's symbolic-ref command: https://github.com/sitaramc/gitolite/blob/master/src/commands/symbolic-ref). Our org is using Gitlab now, and I have been able to put some functionality together using the Gitlab API's, but it's quite ugly, and was hoping that maybe there was an intrinsic git protocol solution, which seems there could be, but somewhere past trivial and before impossible. -Jesse On Sat, Sep 30, 2023 at 11:17 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jesse Hopkins <jesse.hops@xxxxxxxxx> writes: > > > Wondering if it's possible to do the equivalent of the update-ref > > command remotely. Or I guess another way of putting it would be to > > git-push to a remote repository without needing a local clone of the > > repo. > > > > Trying do something like: > > > > git push <remote-repo-url> <sha1>:refs/heads/mybranchtoupdate > > > > where I know that <sha1> already exists on the remote. I'd like to > > avoid the need to clone a local copy of the repo. Wondering if there > > might be some plumbing command(s) that could accomplish this? > > There is no such command shipped with Git. I do not think anybody > ever proposed to add such a feature, as it won't be generally useful > in contexts other than one-shot surgery. > > But that is different from that it is impossible to do. At the > protocol level, as long as the receiving end is convinced that such > a push, which does not transfer any object but proposes to update a > ref to a new value, does not corrupt the resulting repository state > after acceptingit, the receiving end does not care if the sending > end has what object, or even any repository---the receiving end > cannot even know what the sending end actually has. > > The devil however is in the details of ensuring the "as long as the > receiving end is convinced" part. If you know that an object whose > object name is X is sitting at the tip of branch A at the remote, > and you try to update the tip of branch B to the same object, it is > likely [*] that the remote would notice that such an update after > receiving no new objects is safe. But if the object X is not > sitting at the tip of any branch or ref (it may be a few commits > behind an existing ref, or it may be dangling ahead of all refs), it > would depend on how the receiving end determines that it has object > chains necessary to complete the new DAG that has X. The official > versions of Git client historically have done a thorough job in > check_connected() to even discover fully connected object chains > that allows us to resurrect such a dangling tip of a DAG, but we > cannot complain if third-party Git implementations misses less > obvious cases. > > Having said all that, writing a specialized "push lookalike" that > sends the required protocol message that would have been spewed by a > real "git push" client operating in the right environment (i.e., it > has a repository that is a good clone of the receiving repository at > the <remote-repo-url>, the receiving repository has <sha1> and all > the objects that are reachable from it, refs/heads/mybranchtoupdate > points at a commit that is an ancestor of <sha1> right now) should > not be brain surgery, and with such a program you can > > $ git-push-empty <remote-repo-url> <sha1>:refs/heads/mybranchtoupdate > > and fool the receiving end to do what you want it to do, as it > cannot tell if it is talking to a real "git push" client or to your > "push-empty" program from what is coming over the wire. > > >
