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?
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 18.104.22.168.
'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):
public int FooBar()
public String FooBar()
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.
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 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:
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".
A vulnerability has been published today in regards to Sourcetree for Windows. The goal of this article is to give you a summary of information we have gathered from Atlassian Community as a st...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events