Sublime Forum

EOL Normalization: False Positives

#1 
Win 10 x64 | Sublime Merge 1098

This problem was experience with SM 1097 and SM 1098 (I switched to Dev Builds to see if it was fixed).

When I rebuild some HTML documents (via Asciidoctor), SM shows the files as changed, reporting a new <0x0d> (CR) at line ends. This is a false positive, for in my .gitattributes HTML files are configured to be treated as text with native EOL normalization:

*.html     text

And if I open a Git shell and type git status (which reports no changes) then SM refreshes its status too, and the HTML files no longer show up as unstaged changed.

For some reason, SM doesn’t seem to be tracking EOL normalization as expected, and operation with the system installed Git shell update its status to the correct one. Probably, SM is not considering the fact that these files are normalized to native EOL, and sees the extra CR character in the local files which is not present in the checked-in files as an unstaged difference.

0 Likes
#2

Hi @tajmone,

Thank you for using Sublime Merge!

I’m sorry to hear you’re getting inconsistencies. To help diagnose the issue, would you be able to PM me the Sublime Merge debug information? This can be copied to your clipboard via Help > Debug Information.

Kind regards,

- Dylan Johnston
Software Engineer, Sublime HQ

0 Likes
#3

Hi @djohnston, I had mailed you the debug info the same day you posted your reply, but I keep getting bounceback errors from gmail. I had also re-send you the report via another account, which didn’t bounce back. So, I hope that you’ve got the report via the second email account at least.

The bounce back error was from hello@forum.sublimetext.com, which is the sender of the mail copy I received of your post. The error message was:

The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720 [forum.sublimetext.com 104.236.208.78: generic::failed_precondition: connect error (0): error]

0 Likes
#4

Hi @tajmone,

Thanks for getting back to me - I’m sorry that you’ve run into issues reaching us.

When it’s convenient, could I get you to visit the forum at this link: https://forum.sublimetext.com/u/djohnston and select Message on the top-right of the page. From there you will be able to send me a private message containing the debug information.

Kind regards,

- Dylan Johnston
Software Engineer, Sublime HQ

1 Like
#5

This EOL problem has had disrupting consequences on some repositories. Forgetting to use git status via Git CLI before some SM operations introduced conflicts that prevent merging branches.

I can’t understand what’s going on here, but the EOL CR false positive seems to show up only the in SM changed files, but nevertheless it prevents merge operations because it then sees differences between the commited files and those in the working area.

And, somehow, some commited text files seem to prevent merging branches although there should be no conflicts reported.

I’m really struggling to understand the exact nature of this problem, but mishandling of EOL normalization is a serious problem under Windows — add to that the known problems that MS Windows introduces in working with Git when switching branches (files that can’t deleted or changed due to handles), then this whole thing becomes a nightmare.

Basically, in those (production) repositories where this problem creeped in, I’m discovering that I can’t now merge local dev branches back into master — neither via Git CLI nor SM. During merge attempts, the EOL false positives alway creep back in making Git see the files in the working area as changed (although they are not), and merging aborts…

Are there been any progress on this issue? I really hope it will be fixed ASAP.

0 Likes