tags:

views:

95

answers:

2

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.

+3  A: 

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

Some 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 

if 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.

VonC
This is awesome. That's twice in one day :)
Yar
The problem with the logic is, this happens to me when I'm merging into the main branch. Just because git can't figure out the automatic merge doesn't mean it's not totally obvious. But I want the history moving forward. In any case, most of these histories will be rebased into the garbage.
Yar
A: 

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.

anotherAlan
It's worth emphasising that `-Xtheirs` is completely different from a hypothetical `-s theirs` strategy. `-Xtheirs` passes the `theirs` option to the recursive merge strategy which resolves conflicting hunks by choosing the 'theirs' version. `-s theirs`, if implemented like `-s ours` would choose the entirety of 'their' tree instead of any sort of intelligent merge.
Charles Bailey
I think I get that. Does that mean that an "-s theirs" is really the same thing as if you did "git reset --hard BRANCHNAME"?
anotherAlan