Asked  7 Months ago    Answers:  5   Viewed   27 times

When merging topic branch "B" into "A" using git merge, I get some conflicts. I know all the conflicts can be solved using the version in "B".

I am aware of git merge -s ours. But what I want is something like git merge -s theirs.

Why doesn't it exist? How can I achieve the same result after the conflicting merge with existing git commands? (git checkout every unmerged file from B)

UPDATE: The "solution" of just discarding anything from branch A (the merge commit point to B version of the tree) is not what I am looking for.

 Answers

57

Add the -X option to theirs. For example:

git checkout branchA
git merge -X theirs branchB

Everything will merge in the desired way.

The only thing I've seen cause problems is if files were deleted from branchB. They show up as conflicts if something other than git did the removal.

The fix is easy. Just run git rm with the name of any files that were deleted:

git rm {DELETED-FILE-NAME}

After that, the -X theirs should work as expected.

Of course, doing the actual removal with the git rm command will prevent the conflict from happening in the first place.


Note: A longer form option also exists.

To use it, replace:

-X theirs

with:

--strategy-option=theirs
Tuesday, June 1, 2021
 
Ultimater
answered 7 Months ago
76

It seems like you want the files ignored but they have already been commited. .gitignore has no effect on files that are already in the repo so they need to be removed with git rm --cached. The --cached will prevent it from having any effect on your working copy and it will just mark as removed the next time you commit. After the files are removed from the repo then the .gitignore will prevent them from being added again.

But you have another problem with your .gitignore, you are excessively using wildcards and its causing it to match less than you expect it to. Instead lets change the .gitignore and try this.

.bundle
.DS_Store
db/*.sqlite3
log/*.log
tmp/
public/system/images/
public/system/avatars/
Sunday, June 6, 2021
 
Novalirium
answered 6 Months ago
61

As the man page says, -s ours ignores the contents of the other branch entirely. This should be obvious enough: no matter what's in the other branch, the tree attached to the merge commit is identical to the tree in the HEAD commit before the merge.

What -X ours does is more subtle: it uses "our" version of a change only when there's a conflict.

Here's a relatively simple example.

Suppose that you're on branch br1 and you ask to merge in branch br2. We'll make these really simple, with commit B (the merge base origin for both branches) having one single commit K on branch br1, and one single commit L on branch br2:

... - B - K   <-- HEAD=br1
        
          L   <-- br2

Furthermore, the difference from B to K consists of only one item:

  • change (already existing) file f1: replace first line dog with cat

Meanwhile, the difference from B to L consists of:

  • change file f1: replace first line dog with poodle
  • change file f2: replace last line elephant with rhinoceros

When you merge these with no strategy or options, there will be a conflict in file f1 (different changes to the same lines), but not in f2 (the merge commit would take the change in commit L so that file f2 would change).

If you use:

git merge -s ours br2

the merge command will use "our" version of file f1 (dog becomes cat), and also our version of file f2 (elephant is not changed).

If you use:

git merge -s recursive -X ours

the merge command will find a conflict on file f1 and will resolve it in favor of our version—this is the same as before—but there is no conflict on file f2, so git will use their version of f2 (elephant becomes rhinoceros).

(This simple example does not show what happens if there are two different changes in different areas in f1 or f2. If f1 is long enough and there's a change in commit L further down than "the first line of the file", the merge can pick up that change since it won't conflict with the dog-to-cat change.)

Saturday, July 3, 2021
 
RemiX
answered 5 Months ago
88

The error which you see is artificial check of github, which I personally find unneeded. You can revert the revert locally then:

git fetch origin master
git checkout origin/master (or reset)
git revert <REVERT HASH>
git push origin master

This should succeed, modulo conflicts with changes done since the revert.

PS: actually, the error could be because of the conflicts.

Wednesday, August 11, 2021
 
Marcelo
answered 4 Months ago
22

As I explained here:

whatever HEAD's pointing to is "ours"

The one tool that makes cristal clear what is ours vs theirs is VSCode.
See "Resolve merge conflicts"

  • The current change are ours.
  • The incoming change are theirs.

https://raw.githubusercontent.com/microsoft/vscode-tips-and-tricks/master/media/resolve_merge_conflicts.gif

Thursday, November 25, 2021
 
David ROSEY
answered 6 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share