Fix snapshots and tests line-ending in Windows #2166
Conversation
edwin0cheng
changed the title
|
bors r+ |
2166: Fix snapshots and tests line-ending in Windows r=matklad a=edwin0cheng When running `cargo test` in Windows, there are some test and snapshots generated which are `LF` line-endings. This PR try to force `git` to use `LF` for these files. Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Build succeeded |
| crates/ra_syntax/tests/data/** -text | ||
| crates/ra_syntax/test_data/** -text eof=LF | ||
| crates/ra_ide_api/src/snapshots/** -text eof=LF |
There was a problem hiding this comment.
There's no way this could have worked, if you read the documentation:
eofdoesn't exist,eoldoeseolonly works ontextfiles- this makes sense, since it's lossy in general, and only text files can accept the lossiness as "CRLF and LF are two ways to represent the same thing" (line endings
If the goal here was to hide files from git grep, I'm afraid there is no way to do that without leaving the door open to CRLF (\r\n) corruption.
Honestly looking at #1115 I have no idea what's going on. Most likely some buggy tool produced \r\n instead of \n for line endings, which didn't match the correct (\n) ones git was dutifully using.
If it's the other way around, then the autocrlf setting is being set to the cursed option that generates \r\n on the fly from files committed as \n (which is not something you should never need or use - only outdated stuff like notepad.exe needs it).
There was a problem hiding this comment.
only outdated stuff like notepad.exe needs it
Even Notepad supports Unix line endings now: https://www.theregister.com/2018/05/08/windows_notepad_unix_linux_macos/.
When running
cargo testin Windows, there are some test and snapshots generated which areLFline-endings.This PR try to force
gitto useLFfor these files.