On Mon, Apr 16, 2018 at 4:13 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jacob Keller <jacob.kel...@gmail.com> writes: > >> Things won't work so well if you set the push url and fetch url to >> different repositories. Git assumes that refs updated by "push" will >> also be reflected via "fetch". >> >> I don't know offhand what will break, but likely something will. For >> one, when you fetch again it will rewind your remotes after the push. > > Exactly. I still haven't fully embraced it myself, but for a long > time, "git push" pretends as if it fetched from that remote and > updates the corresponding remote tracking branches (if you have > any), so you'll be inviting inconsistent behaviour if you set your > fetch and push URLs pointing at two logically separate places. > > This is a tangent, but there probably should be a boolean that > disables this feature in "git push" per destination repository, > i.e. "when pushing into this repository, pretend that we immediately > fetched from the refs we just pushed to and update the remote > tracking branches we have for them: yes/no". It is not entirely > implausible to envision an overly smart remote repository that turns > a non-fast-forward push into an automatic rebase when it is safe to > do so, instead of failing such a push, and you'd disable the "assume > what we pushed would appear there" when talking to such a remote. >
Not to mention something like gerrit which uses magical references "refs/publish/branchname" which don't actually get generated on the server. Thanks, Jake
