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.
