Sourcetree Merge Conflict Flow has Changed for the Worse

[Oddioengineer]

I'm an artist. For years, I have had the habit of always Pulling before I Commit/Push. Till recently, I would Pull and if there was an incoming merge conflict, the Merge Conflict popup would show up and then I would have an opportunity to right-click the conflicted file and resolve it. Again, all without Committing first.

Now it seems like Sourcetree has changed and it expects me to Commit BEFORE Pulling. Says so in the popup.

WHY has this changed? And is there a way to put it back how it was? I would rather have an opportunity to Reset my file before Committing it, if I don't want to Resolve. And for an artist, un-committing requires a command line.

[Mike Corsaro]

Hello! Which OS are you using?

We enforce this behavior because the docs actually warn about this topic:

Warning: Running git merge with non-trivial uncommitted changes is discouraged: while possible, it may leave you in a state that is hard to back out of in the case of a conflict.

Due to this, I'd advise that you actually do the following:

• Stash your changes before the merge
• Merge the changes. Now your 'base' is up to date with the remote and there won't be any conflicts
• Apply the stash: now it's easy to see what your changes are on top of the newly updated base
• Resolve the conflicts and commit. It's a good idea to also delete the stash if you'd like.

For un-committing: you can right-click the commit in the History view and select "Reverse commit".