Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Merge conflict : each conflict appears twice

Using Sourcetree for Windows 1.6.12

I'm just working through my first merge.  I had a number of conflicts, with each conflicted file showing up twice, like the following image.  One checked, the other unchecked.


Question #1:  What does this mean?  Why does each conflict show up twice?  I clicked on each one and they both seemed the same.

So next I edited the conflicting files to resolve the conflicts, and saved each file.  I was thinking maybe the "conflict" icon would change to something else, but it didn't.   Not sure what to do next, I selected Resolve Conflict / Mark Resolved.  That changed to the following:


Still duplicated, one checked, and the other unchecked.

Now I'm ready to commit, but still concerned about every file showing up twice?  Is it safe to commit in this situation?  Should I uncheck one of each of the files?


Russ Dirks


Edit: insert better images.

5 answers

1 vote
Seth Rising Star Jan 20, 2015

For whatever reason, when there is a conflict, the file in question shows up as both staged and unstaged (presumably portions have been staged, and others have not).

You should NOT use the "Mark Resolved" option unless you have opened the file in your typical editor and manually fixed the conflicts, otherwise you will commit the file with all of the extra conflict markup. 

If resolving merge conflicts is new territory for you, I'd recommend spending some time with google, and maybe find a good merge tool for your OS if you don't like the idea of resolving merges by hand.

If this is not a bug on Windows, then it's not very consistent in macOS (or the other way around?). I frequently use Sourcetree on both platforms, but in macOS, the conflicting files are never duplicated. IMHO, duplicating the file is more confusing because you don't know which one should be marked as resolved (marking either will work because it's the same file, but that's the point, right?).

I just wanted to add my 2 cents on this. I hope it helps to make Sorcetree even better.


Well, I did a bunch of experiments with a test repo, with the command line open as well, running 'git status', and I have discovered the following points.  Keep in mind I'm still fairly new to using git.

  • Displaying the files twice seems to be Sourcetree's way of indicating there was a merge conflict. If you run 'git status` on the command line, you'll see "both added" for that file, which is just your standard merge conflict.

  • Using Mark Resolved is equivalent to 'git add' for that file.  It basically stages the file. This will change the display from two yellow exclamation points to one orange '...' icon. 
  • You can achieve the same thing by simply clicking the unchecked item of the pair of files.
  • The previous point only holds true if you have the UI view set to Fluid Staging or Split Staging View.  If you have it set to No Staging, clicking the unchecked item of the pair of files does nothing.  The Marked Resolved command still works, though.

My personal opinion is that representing merge conflicts by displaying the file twice, one staged and the other not, is overkill.  It is just confusing.  One instance of the file, with a yellow exclamation icon, would be just fine.  It should initially show up un-staged.  When you've resolved it, you just click on it to add it to the staging area, and then commit. 

So Seth was right above, this is the standard merge conflict case. The reason for the file being there twice is that you can stage hunks in a file, so the non-conflicting parts are staged and the conflicting ones are not (until you resolve the conflict). If you can create a merge conflict where the whole file is in a conflicted state (e.g. one-liner with the line changed), it will not show up twice. This is a feature, not a bug.

No, that doesn't seem to be the case.

0 votes

Any chance that your files are read-only or locked for some reason?

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events