Sourcetree (Win) 1.0.3.0 - What happened to my line endings?

thomthom

I updated Sourcetree (Win) to the version that now supports Mercurial repos and added my repositories.

I now find that several files are listed as modified - and it's the line-endings that's changed. I found no way to see the line endings in SourceTree, but I started TortoiseHG, which does let you see line endings - and it showed that the files was changed from CRLF to LF.

I try to discard the changes - but it doesn't appear to help. The file returns as changed and insist on changing line endings.

The odd thing is - Tortoise says that the working copy changes line endings from CFLF to LF - but when I open the file in Notepad++ it says CRLF.

And it's not all files, just a few random ones. Some times just a single froma from a repo - sometimes more.

I did say Sourcetree should handle line endings - I thought Git and Hg was set up for this in any case.

So what is going on?

Why are my line endings changed and why can I not discard them?

Any way to seeing the line endings in SourceTree?

stevestreeting

We've had a few comments on this and from 1.0.4 we'll enable the eol extension, but won't add the [encode] / [decode] entries. This will make your configuration compatible with repositories that use the .hgeol config files to control eol conversion but won't change your existing conversion settings (if any).

We were trying to be helpful here and make sure that by default if you worked on cross-platform projects you would see CRLFs locally but LFs would be stored in the repo for compatibility with Linux and OS X machines, but the trouble is that if you have existing projects with a mixture of line endings embedded in the repo, enabling the conversion will suddenly give you modified files that you have to commit to resolve.

In your case, the files that showed as modified had been stored in the repository with CRLF endings. This would cause problems for Linux/OS X users if they cloned this repo. The extension was showing you that really you needed to re-commit these files - which were still CRLF locally, but really should be stored in the internal repo as LF for cross-platform friendliness, so re-committing them would perform this conversion. You wouldn't see any difference on your local drive but anyone on other platforms would have their issues resolved. I spent 10 years in open source on cross-platform tools and keeping line endings in LF format internally even though on Windows you wanted them as CRLF was always the best option in my experience, so I was trying to set up the most useful situation for new users by default, but it's confused people who have repos which are already embedded with CRLFs internally.

If you don't want to adopt the platform-neutral line ending approach in your repos then you should keep the eol extension enabled anyway (so that any repo that does use it works on your machine), but you should remove these lines:

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

That removes the default conversion to/from the internal repo state, which we won't be adding any more from 1.0.4.