nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

Chris Rusby

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.

All comments

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?

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

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.

Chris Rusby

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.

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.

Piotr13

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?

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.

Zeeshan Khatri

I am facing the same issue;

unknown

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:

I pulled from 'development' to my branch.
There was a one-line conflict, with no consequence to my changes.
So, I picked 'merge using theirs'.
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.

veseli_kacamak

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

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.

Please delete this reply. Sorry.

Matt McLin_9qprgg

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.

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

Steven_8y72ay

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

m r_3dbcuq

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

glerler01

This still hasn't fixed

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree