Merge conflicts resolve using theirs vs mine

It seems to me that if I have a merge conflict and I select "Resolve Using Theirs..." source tree actually resolves using my changes, and if I select "Resolve Using Mine..." source tree actual resolves using theirs!

I have a mercurial repository.

Is this a known feature?

10 answers

1 accepted

I've raised an issue at, as per my comment I will upload screenshots when I next come across this situation. Thanks.

My experience is similar to Kyle's, i.e. I chose the opposite option.

Maybe it'd be easier to apply if instead of Mine/Theirs there are actual branches' names?

'Resolve Using Mine' = the file exactly as the first parent, 'Resolve Using Theirs' = take the *whole file* from the second parent or merge source. I just ran through a couple of tests here and that's exactly what it did.

You do have to remember it just takes the entire file from that side of the merge. That means if you 'Resolve Using Theirs' then you literally just get the file exactly as it was on that other branch, losing any other changes from the current branch. So it's different to resolving in an external merge tool and choosing the 'other' side of the merge for all the conflicts (since that is still merging with the current branch changes). It didn't seem to be reversed when I tried it here.

Thank you for your swift response, I take your point about the entire file.

My issue is that when I preview the file in SourceTree, I see something like this (and apologies it's from memory; I'll provide an exact example when I next have one):

====> mine

public int FooBar()

<==== mine

====> theirs

public String FooBar()

<==== theirs

When I select "Resolve using mine..." the resolved file will have the FooBar method returning String (and vice-versa).
Seems a bit odd to me?

That is odd, because it's not what I see here: - resolving using mine/theirs takes each side as matching the chevrons.

However again it's really important to understand that 'Resolve using X' just takes the *entire file* from that side of the merge as a snapshot, it doesn't do the same thing as taking the 'mine' or 'theirs' changes in the conflict areas. It literally takes a complete snapshot from one or other side of the merge, discarding all changes from the other side (even non-conflicting ones). That's why you only ever use it for binary files or for rare cases where you want to completely discard all changes from one branch in favour of the snapshot from the other.

Steve, seems like your missing the point.  I think we all understand that whether we chose "mine" or "theirs" it takes THAT whole file and none of the other one.  BUT, the  problem is which is "mine" and which is "theirs" it should say the branch names instead of "mine" and "theirs" so we know which is which as piotr suggested.

I emphatically agree with Tim.    "Mine" and "Theirs" have counter-intuitive meanings.   In my experience, SourceTree usually puts up a warning dialog box explaining this, but it's very discomforting..   And I have even founding the warning itself confusing in its disamibiguation of the two terms.   

What would be valuable here is a POSITIVE unmistakeable, confidence-building description of the two options.    It may be a little difficult to describe one side since this occurs in the middle of a merge (in a detached HEAD).    But the target branch that you are pulling things into should always be known even if the source branch isn't.

Another salient point:  This occurs not just during merge, and rebase operations, but also during cherry-picking.

I really hope the SourceTree team will consider this a priority.  IMHO, one of the ways in which SourceTree distinguishes itself is how intuitive it is compared with other git GUIs.

For example, I've never felt comfortable using hunks anywhere other than SourceTree.   SourceTrees GUI there is very intuitive.

I don't have an example to offer; but I have also learned to choose the opposite of what I expected for mine/theirs.

I am facing the same issue;

I also had this same issue today, and it cost me hours... as I had: Created a new repo in bitbucket. Created local repo with SourceTree, set the remote to the new bitbucket repo pushed the project up. Created local repo on second development machine, and done initial local commit, and then set the remote and attempted to pull down changes from the bitbucket reopo. I set all the resolved all the conflicts except a couple Using Theirs, but it actually used mine... I didn't realize this till after I had pushed everything back to the server, and then my source was all messed up and I had to start from scratch all over again.

I always have the same issue with this. I'm actually merging one branch right now and have exactly that:

Picking "Resolve using mine" (changes on my branch that I'm merging into) actually results in SourceTree picking the file AS IS on the source branch (the one i'm merging from).

I'd expect the opposite to happen. This is SourceTree for Mac.

I have experienced this problem too. It happened just now, for at least the third time since Christmas. From now on, I will no longer use SourceTree for merges. Here's what happened:

  1. I pulled from 'development' to my branch.
  2. There was a one-line conflict, with no consequence to my changes.
  3. So, I picked 'merge using theirs'.
  4. Instead of taking that one line, SourceTree took the whole file from the source branch, as-is, which effectively rolled back dozens of other lines in that file.

"using theirs" and "using mine" options has finally fixed on latest update of ST. \O/

Please delete this reply. Sorry.

Besides the situations that have already been mentioned where this confusion of "mine" vs. "theirs" shows up, there is another case that I just ran into that is worth mentioning, and that is when applying a stash.

When applying a stash and a conflict is encountered, "mine" vs. "theirs" becomes completely meaningless, and the warning shown by SourceTree if you select "resolve using theirs" is incorrect. 

If you pick "resolve using theirs", it will select the file from your stash, and the warning message will tell you that this file is the one relating to the commit hash of your branch, which is wrong.  In fact, your stash is not yet part of a commit  If you select "resolve using mine", you will get exactly the same warning message, with the same commit hash, but in that case it will actually do what it says and take keep the file as it was in that commit.

What with all the confusion on this topic over the years, I think it's pretty clear that "mine" and "theirs" is not an appropriate way to reason about conflicting changes.  Instead, the tool should be specific about where the changes are coming from.

By the way, this was for a git repo, and my SourceTree version is

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published May 30, 2018 in Sourcetree

Tip from the team: configuring Git or Mercurial in Sourcetree

Supported Platforms macOS Windows To make using Sourcetree as simple yet powerful as possible we embed (bundle) dependencies such as Git, Git LFS, and Mercurial. We strive to keep these...

556 views 1 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you