tags:

views:

568

answers:

1

In a merge with conflicts, is there a way to tell git to keep one version for a set of files?

$ git checkout some_branch
$ git merge origin/master
$ ?
+5  A: 

If you've already attempted the merge and are looking at the unmerged files, you can use git checkout:

git checkout some_branch
git merge origin/master
<conflicts!>
git checkout --theirs -- <dir>|<file>

(and of course, --ours keeps the version from the current branch)

Jefromi
Thanks for your answer. I tried it and it marks *all* the conflicted files as either "both modified" or "both added", in scary red. First time I see that, so any pointers? My merge is between different branches, in case that makes a difference.
Ivan
That doesn't make a difference - pull is just fetch + merge. As for your status thing - the unmerged files should all start out as "both modified", in the "Unmerged paths" section. After the git checkout, if you examine the file, you'll see that it's been replaced by the indicated version; you still have to add it with git-add, at which point it will move up into the "Changes to be committed" section, in green. I've never seen a "both added" in red before.
Jefromi
Ok, yeah, I was confused about that. I did have to modify it a little, as such: `git checkout --theirs master <dir>`. Thanks again.
Ivan
You should not have to specify a branch. If you do that, I think it's ignoring `--ours/--theirs`. At most you should need to put a `--` to indicate you're giving paths, not options or trees.
Jefromi
Oh, and I had to update to latest, as `--theirs` wasn't available in 1.6.0.4
Ivan
Ah, I forgot it was that recent. That explains why you were surprised by the status messages, I think - they were modified relatively recently as well.
Jefromi
You're right, I got confused because the files stayed as "both modified", but upon inspecting them I see the right version was picked, so I just had to commit them.
Ivan