Re:CRLF is obsolete and should be abolished
by dwattttt on Sunday October 13, 2024 @09:56PM
(#41833488)
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?
Re:CRLF is obsolete and should be abolished
by layer8 on Tuesday October 15, 2024 @04:40PM
(#41852871)
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.
Re:CRLF is obsolete and should be abolished
by Kwpolska on Tuesday October 15, 2024 @03:44PM
(#41852375)
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 correct solution is to use .gitattributes.