SourceTree for Windows v126.96.36.199
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"
"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!
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:
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.
I'm seeing this same issue (discard hunk changes EOL characters) on a fresh install of SourceTree 188.8.131.52 (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.
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!
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.
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.
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!
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:
git config --edit --global
git config --edit --system
Local (for the specific repository):
git config --edit --local
Look at the help for git config to get more info.
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?
This bites me all the time, making Discard Hunk unusable. I'm on Windows 7, using Git and SourceTree version 184.108.40.206.
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.
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?)
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.
Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...
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