all files in this repository (unintentionally?) have CRLF line endings

[decathorpe]

When packaging this crate for Fedora Linux as a dependency for the image crate, we found that all files that are not auto-generated by cargo during cargo publish carry CRLF line endings. This is rather unusual for Rust crates, and there is no config file to configure git to explicitly rewrite files to have CRLF line endings, so I assume this is not intentional.

[johannesvollmer]

This is correct. Not intentional. What problems exactly did it cause on Linux? Some files in particular?

[decathorpe]

It's not causing "problems" per se. cargo / rustc can still read all the files. We just need to do some normalization to remove \r characters, since no files with CRLF line endings are allowed in our packages. I added a bash one-liner to fix this in a source "post-processing" step, but it would of course be better if this was fixed "at the source", especially if it's not intentional :)

[johannesvollmer]

Yes, seems reasonable. Thanks for taking the time to drop by :)

[robinduerhager]

This happens most of the time during development on windows machines since windows defaults to CRLF. You might be able to prevent this by enforcing LF line endings through the configuration of e.g. EditorConfig. This will also help if some local testing or Development is transmitted to some linux based VM or Container. Additionally some .gitattributes file in the repo might be helpful so no CRLF files are pushed accidently to the repo. There is also some ready to use Rust .gitattributes file that you might want to use :). The GitHub Documentation provides a bit more info on this topic and dependencies you might have to check when using a .gitattributes file.

As of why this might be really important: I know this bug very well from the Docker / virtualization point of view. Windows can read LF just fine, however Linux often demands LF and if not provided runs into arbitrary and unexpected errors which might cost some developers a lot of time to fix 😅.