I have checked out the various questions on this. The first provides a huge question and answer (relevant? not sure) and the second provides a wrong answer as best answer.
I have a branch called great-use-this. I have another branch called master. I want to merge great-use-this into master, and avoid auto-merging conflicts.
What is the simplest and easiest way to do this?
Note: I have actually figured this out (using a third branch and ours, but this would be good to have on SO anyway.
Yes, creating a third branch and doing a merge -s ours is one solution.
But You will find the all "let's not advertised any "theirs" merging strategy" here.
Between replacing your work with one other branch work, or simply getting rid of the current work and replacing it completely by the other one, Junio C. Hamano (main Git Maintainer) prefers the second approach:
I think "
-s theirs" is even worse. It is how you would discard what you did (perhaps because the other side has much better solution than your hack), but that can be much more easily and cleanly done with:$ git reset --hard origin/masterSome people might say "But with '
merge -s theirs', I can keep what I did, too". That reset is simply discarding what I did.That logic also is flawed. You can instead:
$ git branch i-was-stupid $ git reset --hard origin/masterif you really want to keep record of your failure.
One big problem "
-s theirs" has, compared to the above "reset to origin, discarding or setting aside the failed history" is that your 'master' history that your further development is based on will keep your failed crap in it forever if you did "-s theirs".Hopefully you will become a better programmer over time, and you may eventually have something worth sharing with the world near the tip of your master branch. When that happens, however, you cannot offer your master branch to be pulled by the upstream, as the wider world will not be interested in your earlier mistakes at all.
Ran into this problem the other day:
httpx://seanius.net/blog/2011/02/git-merge-s-theirs/
Update: Old url is down. Here is the article via Archive.org's Wayback Machine:
git merge -s ours ref-to-be-merged git diff --binary ref-to-be-merged | git apply -R --index git commit -F .git/COMMIT_EDITMSG --amend I'm leaning toward the git reset --hard BRANCHNAME option myself, but I've discovered that there is a "their" in Git (v. 1.7.1 at least).
If you want to try it, just add an "-Xtheirs" argument to the merge command.
For example, starting in master:
git checkout -b editBranch
-- edit your files --
git add .
git commit -m "Updated the files"
git checkout master
git merge -Xtheirs editBranch
If you have deleted any files in the editBranch, you'll get a merge conflit that can be resolved with git rm FILENAME.
Once again, it seems likely that the reset --hard BRANCHNAME is better option, but if you have a case where you really need a theirs, this should get you there.