How Do I Stop SourceTree From Changing Line Endings When Discarding Changes

[Craig Pierce]

SourceTree for Windows v1.0.4.0

Source controlled codebase is C#.NET written in Visual Studio 2012

When I discard a hunk or a file, SourceTree changes every line ending in the file, and every line in the whole file then shows as red (unless I ignore whitespace - which won't change the fact that SourceTree is still messing with my line endings).

How can I make it stop doing this?

I just uninstalled SourceTree, deleted all 'Atlassian' folders from %appdata%, rebooted and reinstalled SourceTree - and during setup this time I unchecked both checkboxes for:

"Allow SourceTree to modify your global config files"

and

"Configure automatic line ending handling by default"

...but that's no good - it still changes all the line endings in a file when I discard any changes.

I REALLY want to be able to use this feature - Please let me know if there's a way to make it stop changing my line endings.

Thanks so much!

[stevestreeting · Accepted solution]

Because the EOL setting is so crucial to apply consistently it's one of the only settings we write to your mercurial.ini at setup time (in %USERPROFILE%\mercurial.ini), which is why it's still there - that wizard setting only adds settings, it doesn't delete them if they're there already. There are 2 settings, firstly enabling the eol extension:

[extensions]
eol=

And secondly - and this was only done up to 1.0.3 - enabling a default set of conversions:

[encode]
**=cleverencode:
[decode]
**=cleverdecode:

From 1.0.4 we do not add the [encode] / [decode] sections any more, and if you remove them from your mercurial.ini then this effect will be 'resolved'. If you want to keep your repositories as-is, the best thing to do is remove the [encode] / [decode] sections from your mercurial.ini - we don't add these in versions from 1.0.4 onwards because although they're useful to get all repositories on a 'standard' footing (CRLF on your local disk, but LF inside the repo so that people on other platforms get their own line endings) if you have existing repositories which haven't been set up like that, so they have CRLFs inside the repo too (which would be a pain for non-Windows platforms to get), then those files show up as modified all the time and you have to re-commit them to apply the line ending conversion.

I could make the case that it's a good idea to do this (recommit the files so they get converted to LF inside the repo for other platforms, while staying CRLF for you on disk), but it does rely on everyone doing the same thing. So our position from 1.0.4 is to only enable the eol extension (so you can leave "eol=" in the [extensions] section), which means that any repositories which are specific about their eol conversion approach will work properly on your machine, but it also doesn't prompt you to 'fix' any existing repositories.

Sorry for the confusion - we were trying to be helpful in creating a default setup but probably went a bit too far initially, bearing in mind that there's a big range of existing repos out there which have treated line endings differently.

To summarise: if you don't want to re-commit the files to convert the line-endings into a platform-neutral format internally then just delete the [encode] and [decode] sections from your mercurial.ini and you can carry on like before.

[Lachlan Gemmell]

I'm seeing this same issue (discard hunk changes EOL characters) on a fresh install of SourceTree 1.0.4.0 (embedded Mercurial) on Win7 with a fresh Mercurial test repository. Neither Mercurial nor Sourcetree has ever been installed on this system before.

My Mercurial .ini does not contain [encode] or [decode] sections.

[stevestreeting]

What are the line endings in the file, and are they consistent throughout the file? SourceTree detects the EOL style to use by sampling the file but it's possible it can get it wrong if there are mixed line endings.

[Lachlan Gemmell]

It's just a dummy file created using standard Win7 Notepad.exe. Each line is just a few random keypresses followed by the Enter key.

[Craig Pierce]

Sorry for the late response - Have been off from work since I posted this question...

I forgot to say in my original question that, when I uninstalled SourceTree and deleted all related files, I also reverted my .ini file back to the way it was before the install. Then (as I did mention) when I reinstalled SourceTree, I unchecked the box that says "Allow SourceTree to modify your global config files"...

Anyway, I've just added "eol=" back to the extensions section and, just like LachlanG, my new install of SourceTree still changes all line endings in the file when I discard a hunk of changes.

Thanks for the responses and the help - I hope we can figure out the fix for this!

[Lachlan Gemmell]

Here's a video demo of the issue.

http://www.screencast.com/t/y97e9wuw

[Craig Pierce]

Any word on if/when this will be fixed?

Thanks!

[stevestreeting]

I've been trying to figure out why it occurred - because I'm used to working in cross-platform projects I have a generic set of EOL conversions configured already (all committed files are converted to LF internally, CRLF on disk), and when you have that set up, this problem doesn't happen. The "eol=" configuration only enables the ability to do EOL conversion, it doesn't enable anything. Even so, since nothing is being committed here I'm not sure why this should matter. Still trying to fix it, although I do have to 'break' my own default configuration to re-create it which is why I've had to work on it in small portions.

[stevestreeting]

OK, I've finally figured out a way to make this work for both sets of users - those who have EOL conversion enabled for text files, and those that don't - up until now I'd only managed to break it for one or other case. It was a bit of a struggle because hg doesn't actually have any tools for figuring out whether a file is going to be treated one way or the other.

While this is working now, I'm going to keep it back from the next update (today) because I feel it needs a bit more testing still. But this should work for those without EOL conversion soon.

[Craig Pierce]

Awesome - Thx for working on it - Can't wait to see it in action!

[Mark Barrett]

This is still happening for me on Windows ST v1.4 when I discard a hunk or a set of selected lines. I dimly remember this working briefly not long after this post was published, and then as I updated it broke again. I'm using Git rather than Hg, so the explanation around removing lines from my mercurial.ini doesn't help very much. Please advise. Thanks!

[Andrew McDonald]

I take it this isn't fixed yet? When I discard changes using Windows SourceTree 1.4.1.0 I see my files' line endings have changed to Unix-style.

Not only that, but the files' security settings have been changed too!

[Dan Pidcock]

I am using SourceTree 1.6.4 and stil l seeing this behaviour. I don't understand why this answer is marked as accepted as it doesn't address the question.

[dangmug]

I don't know if this is dead or not, but this problem has been driving me crazy for a while on my system using git and I just fixed it.

For me the problem ended up being the setting core.autocrlf in the git config files. It was set to true in two of the config files and not present in the other. I had to set it to false where it was present and that fixed it.

You can check if this is your problem by opening the source tree terminal and running:

git config --get core.autocrlf

If it is set to true, If it is then this is your problem.

There are three git config files where this could be set. You can view and edit each one by typing this in the source tree terminal:

Global:

git config --edit --global

System: 

git config --edit --system

Local (for the specific repository):

git config --edit --local

Look at the help for git config to get more info.

[mdutton]

You can use `git config -l --show-origin` to see which file contains the setting.

[sschilz]

This is happening to me on Source Tree 1.6.12.0 on Windows 8.

As far as I am concerned 'dangmug dangmung's answer is NOT a solution. I need autocrlf = true.

This is a bug in Source Tree, see: https://jira.atlassian.com/browse/SRCTREEWIN-2377

[Jasmin Ibrisimbegovic]

What is the valid value for "eol="

is it "eol=true/false"

[Don Williamson]

This bites me all the time, making Discard Hunk unusable. I'm on Windows 7, using Git and SourceTree version 1.4.1.0.

I do also have Hg installed and my INI file has been modified by an older setup to include the settings specified above. I removed them and restarted SourceTree but the issue still exists.

[plunket]

I'm curious about this too; I work on Windows and OSX and for a large set of files I'm just happy with them having UNIX line endings. This may be a holdover from when I used Perforce (which did nasty things in any setup other than keeping everything everywhere as UNIX line endings); the only application I've ever encountered that had trouble with them was notepad.exe so UNIX line endings it is! So my vimrc files, for instance, can happily exist with LF line endings and everything just works happily.

I'm not sure if going CRLF for the Windows checkouts is a problem, per se, but I'm seeing this in my git repo; certainly the Mercurial config doesn't have any effect on that?

[Pedro Mota]

any solution? I am having this issue all the time - changing Line Endings
v3.2.6

[Andy]

In my case, adding kDiff an an external merge tool, then launching it to deal with merge conflicts worked.  It automatically resolved the line ending differences.

[Keith Deane]

I'm still seeing this issue on SourceTree 1.5.1 on Windows 7 with a Git repo. It makes clean up when staging commits very painful as Discard Hunk changes the line endings across the entire file. None of the other staging operations in SourceTree seem to suffer from this issue.

[plunket]

This hit me in the other direction recently; I've been doing a lot of development on Windows lately but just started integrating Cygwin into my workflow; before (when I used Perforce) I could share one vimrc between Windows and Cygwin but it seems that vim on Cygwin chokes on Windows line endings in its config files. So now that means that any time this file is updated via git (since I work across several computers) I need to run d2u on the file or otherwise manually update the line endings to how they were when I committed the file in the first place. :(

(Spambot thinks this is spam so won't let me post it as a comment?)