Cargo always writes lock file with Unix-style line endings

[rschmitt]

I've noticed that when developing on Windows, running pretty much any cargo command causes the Cargo.lock file to be rewritten with Unix-style line endings. This, in turn, causes it to show up as changed in git status. I'm currently working around this by adding the following line to .gitattributes:

Cargo.lock eol=lf

This forces git to check out Cargo.lock using Unix-style line endings, overriding the global config setting of core.crlf=auto. It prevents the diff/status noise, but it's still kind of annoying.

[alexcrichton]

What version of git are you using? I've never had this problem come up in working on Windows. cc @retep998, have you seen this before?

[retep998]

Changing the line ending style does indeed cause Git to think the file was modified.

[rschmitt]

Yeah, the git version isn't nearly as relevant as the configuration. If you're checking everything out with Unix-style line endings, for instance, you'll never notice anything.

[alexcrichton]

@rschmitt I don't have any extra git configuration, so everything "just works" with whatever the defaults are, so I'm curious what your set of defaults are (e.g. git version)

[rschmitt]

The most important setting here is core.autocrlf. When set to true on Windows, it will cause git to check out text files with CRLF line endings, but commit LF endings. This behavior can be overridden or extended within a repository using the .gitattributes file.

[rschmitt]

You can get the global value for this config key on your machine by running git config --global --get core.autocrlf.

[rschmitt]

And to be clear, the default behavior is to leave line endings alone. This inevitably results in a lot of inconsistency from file to file, but it would explain why you've never noticed this behavior before.

[alexcrichton]

Can you check what version of git you are using? I'd like to know why this is a problem you're seeing and why it's not a problem I'm seeing. For example I have no git configuration for core.autocrlf, and I'm just trying to get a better understanding of what's going on here.

[rschmitt]

Right, if you have no git configuration for core.autocrlf it defaults to false, and you'll never see line endings change. But anyway, this is about a bug in Cargo, not git. Git is just how I came across the problem. This is an extremely common type of bug that comes from hardcoding \n as a line ending, instead of whatever the portable equivalent is in the language in question. In fact, the responsible code is right here. There's even a test that asserts that the parser is not allergic to Windows-style line endings. There's an abandoned-looking RFC to add a standard library function that returns the current platform's line separator, but fortunately it's not rocket surgery to just create your own NEWLINE constant using cfg attributes.

[alexcrichton]

Currently I believe that the pretty printer in the compiler also does not print \r\n, just newlines. I believe that the default configuration for git protects you from changes like this, as well. Overall this topic has been debated in rust-lang/rust before, and the conclusion has been to stick to newlines. As a result I'm going to close this, but like the closing comment of rust-lang/rust#24696 I think it'd be fine to open an RFC on this topic to get some broader discussion.