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.

Reply via email to