Git's autocrlf-true interacts badly with cargo rewriting the lockfile

[gkoz]

If git has core.autocrlf=true (a reasonable thing on Windows) it checks out Cargo.lock with CRLF line endings. The next time cargo touches the file, it changes the line endings to LF making git think that it has changed.

Some possible solutions/remedies:

• preserve the line endings in Cargo.lock (perhaps not exactly preserve but detect the kind from the first line);
• in cargo new --bin create .gitattributes with the line Cargo.lock eol=lf;
• document this issue somewhere.

[alexcrichton]

I'm still a little baffled about why this is coming up sometimes and not others, perhaps you can help me clear this up? The git documentation seems to indicate that you should set autocrlf to true on Windows if you're also working with non-Windows developers, but I've never done this on the Rust repo and I've never had problems. I also haven't ever had problems working with any of my other repos without having autocrlf to true, so why is it necessary sometimes?

I'd prefer to avoid .gitattributes as it probably just indicates that there's something else wrong somewhere, and otherwise I'll also cc #1722

[gkoz]

Given that the problem is predicated on core.autocrlf=true being set are you wondering why someone would do that? Because editors and other utilities are all different I guess.

A smart editor (like vim) will just work and probably preserve the line endings style so you won't notice any discrepancies or gratuitous diffs.
An archaic editor (nvi) will show ^M symbols when given a CRLF file and will insert LF when you press enter, introducing inconsistencies.
A stupid editor (notepad.exe) will choke on an LF file.
The advice to set autocrlf=true is aimed to let all of them happily ignore the other convention.

I would advocate for cargo to behave like a smart editor and preserve the line endings style.

[gkoz]

I have a quick and dirty patch for preserving CRLF line endings but it keeps failing my own test 😞

[alexcrichton]

Ok, I think I'm convinced that we should move forward with this, feel free to submit a PR @gkoz!

[retep998]

This is a thing I run into myself sometimes. Definitely having Cargo try to preserve the line ending type would be convenient.

[gkoz]

I'm going to submit a PR shortly but I'd appreciate someone taking a look a the patch above to help me figure out why the test fails.

[gkoz]

It could be because I don't have a slightest idea what p.cargo() and p.cargo_process() actually do... 😕

[alexcrichton]

Oh huh I thought I commented on that awhile back, sorry about that! In short, the first command should use cargo_process as that function will delete the project tree and recreate it, and then future calls to cargo should use p.cargo() as they'll just use the existing tree.

Feel free to open a PR, however, and I can try to help debug through travis as well