Yes, that's correct. Enabling the eol extension provides the ability to do the conversion, but doesn't do it unless rules are matched which triggers it (the encode/decode settings set this to automatic, ie all text files, but we dropped that). encode/decode actually come from the old win32text extension but work with eol too, if you're using .hgeol there's a new format to use - you set the 'native' line ending format (the one inside the repo), and then set 'patterns' to match which files to convert into the native format (and back again). More details here: http://mercurial.selenic.com/wiki/EolExtension

Thanks for explaining the issue a bit more. Just to make sure I understand correctly: if the eol extension is enabled, and I don't provide a default EOL in .hgeol (or don't have that file) and I commit changes to a file using CRLF, it will not be converted to LF? When does the eol extension do conversion? Only if encode/decore are set?

Sorry about that, but just enabling the extension shouldn't cause any line ending changes by default, it's the encode/decode which does that (which is why I removed that from 1.0.4). Having the eol extension enabled just means that if a project does have a .hgeol configuration inside it, your client will obey the rules.

I've never really understood Mercurial's position on treating eol conversion as last resort, since Git (and Subversion / CVS before them) recommended the opposite. If you don't use eol conversion in a multi-platform project, half the people have to remember set their editor line ending settings to the opposite to what's native for their platform. I ran a large multi-platform open source project for 10 years, and trying to rely on people getting their editor settings right usually resulted in complete disaster. Maybe devs on other projects are less fallible. Of course if you're only ever working with one platform then you don't have to use eol conversion and often existing projects don't have it for this reason, which is why the default encode/decode was a step too far and we took it out.

Since the Mercurial docs refer to the eol extension as a Feature of Last Resort and strongly suggest NOT using it, it seems that it shouldn't be enabled by default with or without cleverencode/cleverdecode.

This caused us some headaches, since we didn't realize the extension was enabled, and ended up with changes to the same file in different branches with different line endings. This in turn made merging those branches a hassle (and that's after we figured out what the was happening).

Actually cleverencode/cleverdecode works fine with the eol extension in my experience (the hg mailing lists indicate the eol ext always intended to respect those too).Usually the problem is that the repo has been committed to without win32text or eol enabled and so there are embedded CRLFs in there already which then behave incorrectly when pulled into the working copy with eol/win32text enabled.

However, I've had a few reports of people not liking the default enabling of cleverencode/cleverdecode so I've changed the behaviour for the next update. If the setup wizard 'Enable line ending handling' checkbox is enabled we will only enable the eol extension, and not add default encode/decode settings. This means that unless your repo has a .hgeol file or you manually configure patterns then nothing will happen. The main thing was to try to make sure new users were set up in the way that would behave the right way by default but perhaps we over-reached on the first try.