←back to thread

CRLF is obsolete and should be abolished

(fossil-scm.org)
422 points km | 1 comments | 13 Oct 24 19:16 UTC | HN request time: 0.001s | source
Show context
djha-skin ◴[13 Oct 24 20:08 UTC] No.41831122[source]▶
> 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/

replies(2): >>41831938 #>>41832500 #
Kwpolska ◴[13 Oct 24 22:59 UTC] No.41832500[source]▶
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.
replies(3): >>41832761 #>>41833176 #>>41836850 #
layer8 ◴[14 Oct 24 01:02 UTC] No.41833176[source]▶
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.

replies(2): >>41833488 #>>41852375 #
1. Kwpolska ◴[15 Oct 24 19:44 UTC] No.41852375{3}[source]▶
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.