CODEWITHSUNDEEP
git
user994165
user994165

Reputation: 9512

Git Merges when using Multiple Remotes

I have my remote set up the following way:

git remote set-url origin --push --add <a remote>
git remote set-url origin --push --add <another remote>

based on this question: pull/push from multiple remote locations

Other people on my team only access the first repo. I have 2 machines. My first machines has access both remotes as described above. My second machine only has access to the second repo. My first machine's git remote show origin shows (based on the configuration above):

Fetch URL:  <the_first_remote>
Push URL:    <the_first_remote>
Push URL:    <the_second_remote>

As I understand it, you can't have two Fetch URLs with this approach. From my first machine, I normally do a git pull --rebase and git push to both remotes, and specify the branch when doing so (both in the the pull and push) This works fine except in the following scenario. In my second machine that can only access the second remote, I push a commit to that second remote. In the meantime, someone else pushes a changes only to the first remote. On my first machine (with both remotes set up as above) I pull in both changes and push them out to sync everything up. At this point I get this error message

hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.

So I end up having to do a git pull (without --rebase) or git pull --no-commit to do a merge. The log ends up showing a merge commit. Is there any way to avoid this?

Upvotes: 0

Views: 85

Answers (1)

Scott Weldon
Scott Weldon

Reputation: 10217

Adding multiple Push URLs to a single remote is generally only useful when you want to automatically push to all of those URLs any time you push. In this case, it'd be better to use two separate remotes:

git remote add origin <first url>
git remote add gitlab <second url>

On your first machine, assuming you are behind both remotes, do:

git pull gitlab # --rebase should be unnecessary
git pull --rebase origin master
git push origin master
git push gitlab master --force-with-lease

The last line is what will fix your error. Since you're rebasing your commit onto another user's commit, you must force-push to update the second remote.

In addition, be sure to pull your second remote first, because then you will have your commit locally, which enables pull --rebase to work as expected.

Visualization: your history probably looks like this:

           C [origin/master]
          /
*--*--*--A [master]
          \
           B [gitlab/master]

The first pull command will fast-forward your local master to commit B. The second command transforms the history to look like this:

             B' [master]
            /
           C [origin/master]
          /
*--*--*--A
          \
           B [gitlab/master]

Thus the final two commands: fast-forward push to origin, and force-push to gitlab.

If you have already e.g. pulled the commits in the wrong order, you can fix that by doing:

git reset --hard A

and then following the steps above.

Upvotes: 3

Related Questions