I am looking into the behavior of line endings for several tools. I would like to eliminate the possibility of large diffs due to line ending changes. These can lead to merge conflicts, the hiding of important changes and they reduce the effectivity of git blame.
While working on Windows, I expected cargo init
to create a Rust project with Windows style carriage return '\r' (CR) line-feed '\n' (LF) line endings. However, it seems like the generated files have Unix style LF line endings.
GitForWindows by default sets core.autocrlf = true
on installation. This setting makes git rewrite line endings on check out to the native line ending style (CRLF on Windows) and back to LF on check-in. If you generate a new project and add it to the repository, you are presented with the following:
warning: in the working copy of '.gitignore', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'Cargo.lock', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'Cargo.toml', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'src/main.rs', LF will be replaced by CRLF the next time Git touches it
Git is telling us that when it checks out those files, they will have CRLF line endings instead of the current LF line endings. Fortunately, the rust tools do work irrespective of the line ending style and so this is not a functional issue. However, the warning message can confuse developers who have never had to look into this topic. We can configure git in the repository not to rewrite line endings for these files, or to use a specific line ending style for certain files through .gitattributes
.
One could argue that a version control system (VCS) is responsible for versioning files, not for modifying them. However, I believe that VCSs are responsible for enabling collaboration. If that means rewriting text files for maximum tool compatibility under certain operating systems, then it should do that.
I am surprised that this is the current state of things. I do not think that it is wise to go against the operating system's native line ending style if we can avoid it. If we do so, we are invalidating the default configuration of most tools on that platform. A non-default configuration then needs to be added for the tools that a team is using in the form of .gitattributes
, .vscode/settings.json
, and so forth.
I found some issues in the cargo issue tracker that are relevant. However I did not find anything on why the current implementation of cargo uses LF only.
Can anyone shed some light on this topic?