CRLF is obsolete and should be abolished

> Let's make CRLF one less thing that your grandchildren need to know about or worry about.

The struggle is real, the problem is real. Parents, teach your kids to use .gitattribute files[1]. While you're at it, teach them to hate byte order marks[2].

1: https://stackoverflow.com/questions/73086622/is-a-gitattribu...

2: https://blog.djhaskin.com/blog/byte-order-marks-must-diemd/

The letters after the dot in my filename don't map 1 to 1 with the file format.

Nope. Git should not mess with line endings, the remote repository not matching the code in your local clone can bite you when you least expect it. On Windows, one should disable the autocrlf misfeature (git config --global core.autocrlf false) and configure their text editor to default to LF.

3000% agree. I have been bitten endlessly by autocrlf. It is absolutely insane to me that anyone ever considered your having your SOURCE CONTROL tool get/set different content than what's in the repo

This is impractical in many situations, because tools that process build-source files (for example XML files that control the build, or generated source files) inherently generate CRLF on Windows. These are many, many, many tools, not just one’s text editor.

The correct solution is to use .gitattributes.

If you're using tools that only support one particular line ending, the solution isn't to convert your source automatically in the repo, it's to know your source is always stored in one format, and convert it back/forth when a tool needs it to be different.

How would you handle two different tools only supporting disjoint line endings?

Sure, don't use autocrlf. But some _windows_ tools need crlf, like for powershell or batch build scripts. Defaulting to lf in the editor will not save you.

Don't use `auto`, full marks, but the gitattributes file is indispensable as a safety net when explicit entries are used in it.

I mean, the whole point of the file is not everyone who is working on the project has their editors set to lf. Furthermore, not every tool is okay with line endings that are not CRLF.

When used properly (sure, ideally without auto), the git attributes file as a lifesaver.

Powershell doesn't care about line endings, and hasn't since 2006 when v2 was launched. I have never seen v1 installed but

When LF doesn’t work (e.g. in cmd), you can always use something like .editorconfig to tell editors to use CRLF, and you should keep those files as CRLF in the repo.

If everyone’s on Windows, or if the tool always generates/requires CRLF, then you should store the files with CRLF line endings in the repository. In a mixed Windows/Linux environment, I would still prefer to handle this myself rather than expecting Git to mangle line endings.

The tools generally don’t care about the line endings on input, but they do generate their output using the platform’s line endings. If you don’t normalize the line-endings upon commit, then using the tools on Unix and Windows will alternatingly switch the line endings in the repo between LF and CRLF. And you don’t want to have those constant changes in your history and in the diffs.

Having Git normalize line endings for the relevant file types upon check-in is by far the simplest solution to this problem, in particular since having .gitattributes in the repository means that all clients automatically and consistently perform the same normalization.