If you can't or don't want to update to the latest EGit, then the most reliable work around is (as robinst suggests) to recover from this state and then merge on the command line.
- Note that it is important to recover from this properly, as a
Multiple merge bases problem leaves your repository in the middle of a merge state.
- If you don't recover properly then the next commit you do will result in a merge commit which silently reverts all remote changes!
- In other words, when you push, only your local changes will end up on the remote. All of the remote changes will look like they have been merged in, but will have been ignored, just like doing
git merge -s ours before doing a push.
You can check to see if you are in a merge state by looking for MERGE_HEAD and MERGE_MSG files in your .git folder. Just doing a git status tells you nothing to commit:
$ git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 4 and 25 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
$ cat .git/MERGE_HEAD
1234567890abcdef1234567890abcdef12345678
$ cat .git/MERGE_MSG
Merge remote branch 'origin/master'
You can then return to the state you were in before you attempted the merge from EGit.
$ git reset --hard
HEAD is now at 0123456 Blah blah blah
$ cat .git/MERGE_HEAD .git/MERGE_MSG
cat: .git/MERGE_HEAD: No such file or directory
cat: .git/MERGE_MSG: No such file or directory
As always, this will lose any and all changes made since the last commit.
- Note: This is why it is a good idea to commit all changes before doing a pull or a merge.
- If the pull or merge fails and your repository is left in an inconsistent state, you want to be able to reset back to a known good point before trying the pull/merge again.
- As an alternative to committing before a pull/merge, you can also stash your changes, perform the merge and then unstash them. This is effectively like a mini rebase of uncommitted changes on top of the merge, but with the safety net of a pre-merge commit.
Note that you could also do a git merge --abort, but on some versions of git, this recommends that you commit your changes, which you should not do if you want to avoid your remote changed being silently reverted (which you definitely don't want).
You can now re-run the merge you originally wanted using the git command line, which will use the recursive resolve strategy and should thus work properly:
$ git merge origin/master
Auto-merging ...
...
Merge made by recursive.
...
$ git --no-pager log -1 --oneline
2345678 Merge remote branch 'origin/master'
