Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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?

11 answers

1 accepted

1 vote
Answer 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?

YES! this makes so much more sense, difficult to believe that 5 years later this is still an issue!

Like # people like this

this would be wonderful.  It's ridiculous I am googling this to figure out what is going on

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

This still hasn't fixed

How is this even an exposed menu command if it loses the work in the base file?  And no, the warning dialog is just covering up a very broken command.  This just happened to me, and I lost changes that I had to manually restore.  SourceTree only shows the diffs between the files, but not the changes in the base file.  When you select "theirs", then the base file changes are all lost.

What is needed here is "resolve merges mine" or "resolve merges theirs".

I am facing the same issue;

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

1 vote
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jun 16, 2013

'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?
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Jun 17, 2013

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.

Please delete this reply. Sorry.

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

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.

Deleted user May 24, 2016

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

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events