When committing using Mercurial, all lines in every file will be modified, causing merge conflicts.

steverukuts

Hello,

I was really excited to see the Windows version of SourceTree, as I used it a lot on OSX. Unfortunately, I've just had to ban the usage of Windows SourceTree in my team because it (seemingly) randomly generates commits that will always generate merge conflicts.

On all files, no matter what the change is, the entire file is shown first in red, with every line marked as deleted, and then below in green, the entire file once agin. Of course, I can work around this by selecting "ignore whitespace". This was an annoying UI problem, but then I discovered that this issue actually manifests in commits as well.

I now have in my repository a number of files where this has happened; the entire file contents have been removed and rebuilt using either a different encoding or line-ending or something, meaning it is not possible to tell what has changed in the file without some sort of diff tool. This will also make any merge fail.

However, this doesn't happen all the time. It definitely happens whenever I attempt to revert a file through the file log interface (speaking of which guys, how about a "Revert" option in the context menu?)

I will now have to rebuild my current feature branch. Fortunately, none of this code ever made it into the mainline. That's the price I pay for living on the cutting edge, I guess.

You might suspect that this is down to some sort of hg configuration issue, but this works perfectly with TortoiseHG, which I'd prefer to never use again if I could. I inspected the contents of the SourceTree folder, but I couldn't find a bundled hg.exe so I'm assuming it's using my system hg in c:\Program Files\TortoiseHg\.

Are there any suitable workarounds?

I'd really love to get this working. Please let me know if you want to set up some sort of remote debugging session or if you need any info from me.

stevestreeting

Sorry about this - we do actually have checkboxes in the setup wizard which is where this is set up:

But I realise it's easy to just 'Next' through this without realising the implications. This is the only point where that EOL setting is changed.

Having worked on a lot of cross-platform projects enabling EOL handling is pretty standard, and we didn't get any issues from Git users on this, but it appears that more Hg users on Windows prefer to embed platform-native EOLs in their repos. In future we'll enable the EOL extension, but will not add the [encode] / [decode] sections so nothing will happen unless you manually configure it. We were genuinely trying to be helpful to new users but that seems to have backfired in this case, so apologies for that.