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.
