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?
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.
Thank you for that explaination. That helps a lot. Now I understand (mostly) what's going on. (What puzzles me is how some repos only have one of two files like this.. :s)
But at least now I know what it is and I can control the migration. For some of my projects I'm in the middle of doing some work - and it would not be a good time to suddenly convert everything at that stage.
I checked the backup system for one of these files - it's not been changed. Last change was 3rd of May. But for some reason it's been listed modified - every line.
I did find that mercurial.ini was recently changed - matched the time of updating Sourcetree.
These lines where added:
[extensions] eol= [encode] **=cleverencode: [decode] **=cleverdecode:
Commenting out the eol realted line in mercurial.ini solved the issue though. But I still wonder what is going on.
When I check the file with a hex editor it's clearly CRLF endings - which all the files I open have. But for some reason a select few files show up as modified - and Tortoise will claim CFLF endings has been changed to LF.
I don't understand what'd going on with this...
Have you ever noticed that fixing specific problems might be a door opener for a bigger challenge, affecting a wider audience? This was exactly the case when we, as a service company working with mul...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs