Merge conflicts resolve using theirs vs mine

[Chris Rusby]

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?

[Chris Rusby · Accepted solution]

I've raised an issue at https://jira.atlassian.com/browse/SRCTREE-1670, as per my comment I will upload screenshots when I next come across this situation. Thanks.

[Piotr]

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?

[Steven]

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

[m r]

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

[Matt McLin]

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

[glerler01]

This still hasn't fixed

[alecazam]

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

[Zeeshan Khatri]

I am facing the same issue;

[Kyle Cordes]

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

[stevestreeting]

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

[Chris Rusby]

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?

[stevestreeting]

That is odd, because it's not what I see here: http://screencast.com/t/dXTVRwOrUWVZ - 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.

[Tim Ahrens]

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.

[David Blickstein]

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.

[JM]

Please delete this reply. Sorry.

[veseli_kacamak]

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

[Roberto Andrade]

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]

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.

[Tim Sargent Billing]

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.