Hi @Araq, sorry for the late reply, > Hey, wait a second, I didn't say that! I said git shouldn't touch the > newlines.
The reason I said "I've learned that..." is because of tools like c2nim output Nim sources with LF even on Windows (that was the original question on the repository Issue). Since you confirmed to me that using LF as EOL in c2nim is the expected behavior, then it makes sense to set Git to use LF on all Nim sources — otherwise one would have to create separate rules for manually coded Nim sources and sources generated by Nim tools. The EOL problem only affects Windows users, and unless the repository `.giattributes` file is properly set the risk is that Windows users might commit to the repository index files with CRLF EOL — which indeed would be a problem for Linux and macOS users. Unless explicitly set to LF, Git would normalize text files to the native EOL, which under Windows is CRLF. Unfortunately, the Nim documentation doesn't mention best practice regarding source files and EOL usage, so the various Nim editors extensions use different defaults (e.g. Sublime Text uses native EOL) — the whole idea in creating this template was to provide some ready to use presets, so any advise on how to improve it are indeed welcome. Quoting your reply to the original Issue: > The EOL convention is LF-everywhere indeed. And git should always be > configured to "don't touch the newlines" anyway, how else can you write tests > that contain CR-LF for Linux? The above can only be achieved by telling Git to normalize Nim sources to LF — if you use native EOLs then Git will indeed need to touch newlines under Windows and convert them at checkout from LF to CRLF. But the main issue is that sources auto-generated by Nim tools use LF, so it makes more sense to also adopt LF in the editor to avoid a double standard. Does it make sense?
