Uploaded image for project: 'Sourcetree for Windows'
  1. Sourcetree for Windows
  2. SRCTREEWIN-708

Possible error with Mercurial line ending handling configuration

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • 1.0.4
    • 1.0.2
    • Mercurial
    • None

      I've installed an update of SourceTree yesterday, and this morning I happened to have an issue related to line ending handling.

      A detailed explanation of the problem and solution is available at http://stackoverflow.com/questions/17362377/binary-equal-files-show-as-modified-unable-to-revert

      Summarised, I think SourceTree has mixed configuration of the eol extension with configuration of the old win32text extension. Would you be able to verify this in your codebase?

            [SRCTREEWIN-708] Possible error with Mercurial line ending handling configuration

            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

            Steve Streeting (Inactive) added a comment - 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

            NikolasM added a comment -

            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?

            NikolasM added a comment - 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.

            Steve Streeting (Inactive) added a comment - 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.

            NikolasM added a comment -

            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).

            NikolasM added a comment - 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.

            Steve Streeting (Inactive) added a comment - 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.

              sstreeting Steve Streeting (Inactive)
              22e1aa050182 Stijn Herreman
              Affected customers:
              0 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: