35

Let's suppose that I get a merge conflict on foo/bar.txt when running this:

$ git checkout A
$ git merge B

I'd like to automatically resolve the conflict by taking foo/bar.txt from branch A. (I know what I'm doing, and I do need this. The version in branch B is wrong, and I don't care about losing changes in the working tree in this case.) It seems that I can do it by running these commands:

$ git reset    foo/bar.txt
$ git checkout foo/bar.txt

Is there a simpler, single-command solution?

Unfortunately these commands change foo/bar.txt even if there is no conflict, and I don't want that. If there is no conflict, I want want to keep foo/bar.txt in whatever state git merge B has left it.

So I need a Unix shell command, which would detect if there is a conflict in foo/bar.txt, and if there is, it would resolve the conflict by taking the version of foo/bar.txt from the current branch. It wouldn't do anything else, i.e. it wouldn't modify other files, it wouldn't commit the changes, and it wouldn't change foo/bar.txt if there is no conflict in that file.

pts
  • 80,836
  • 20
  • 110
  • 183

3 Answers3

27

You can specify the merge strategy option ours to the recursive (the default) merge strategy. It will do a normal merge, but in case of conflicting hunks will choose the version of the current branch.

git checkout A
git merge -X ours B

Note that this is very different from -s ours, which selects a different merge strategy. Doing so would throw away all changes of the other branch and only keep our version.

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Thank you for this additional information. Unfortunately it doesn't answer my question, because the `git merge B` command (and possibly many other uncommitted filesystem changes) has already been run. – pts Jan 06 '13 at 13:05
  • 1
    If you have already run the merge command, then you must use the `reset && checkout` method. – knittl Jan 06 '13 at 13:28
  • The reset+checkout method is not an answer to my question either, because it's not a no-op if there is no conflict (see the question for details). – pts Jan 06 '13 at 15:51
  • @pts: yeah, but I didn't say you have to do it unconditionally. And it's not a no-op, because there might be unconflicting changes which get merged just fine by Git's automatic conflict resolution. – knittl Jan 06 '13 at 16:08
20

If you want to do it as a one-off, the single-line command is:

$ git checkout --ours foo/bar.txt  # <-- resets it only if the merge found conflicts in this file
$ git checkout HEAD -- foo/bar.txt # <-- resets it to that specific version no matter what

To configure git's merge to permanently ignore all upstream changes to a locally-changed file:

$ git config merge.pin.driver true
$ echo foo/bar.txt merge=pin >> .git/info/attributes

(true above is just the unix true command, its success says it made the local version look right, in this case by doing nothing to it. You can of course get more sophisticated with your merge commands.)

I think you don't want merge --strategy=ours or --strategy-option=ours, those apply to entire merges.

jthill
  • 55,082
  • 5
  • 77
  • 137
-1

Checkout to target branch and merge with master and automatically can resolve with theirs conflict

git merge -X theirs master
Mohammad Fallah
  • 976
  • 11
  • 14