There are lots of questions here about handling line endings in Git. However, one question I haven't seen addressed is whether using EditorConfig has any implications for how Git should deal with line endings.
I ask because virtually all projects I work on have an .editorconfig
that sets end_of_line
to lf
. This is fine with me, but the standard advice for setting Git's line-ending handling in Windows is to set autocrlf
to true
(ie. convert to CRLF on checking out).
In this situation, Editorconfig and Git seem to be pulling in opposite directions (Git will convert line endings to CRLF on checkout, but then Editorconfig will presumably convert them back to LF whenever a file is saved). So I'm wondering if the use of Editorconfig makes the best practice with line-endings on Windows different?
Note:
My inclination is to defer to Editorconfig and add a .gitattributes
file containing * -text
(ie. tell Git not to touch line-endings, regardless of autocrlf
setting) to every project that has an .editorconfig
file that specifies line endings for the project (I know for a fact that everyone working on these projects uses Editorconfig and/or is using an OS that uses lf
endings, and this seems to avoid the irritating line-ending conversion warnings that Git often seems to spew out in Windows). The problem is, despite lots of reading on the topic, line-endings in Git continue to baffle me, so I'm not confident that the above won't introduce new issues (a previous experiment with .gitattributes
ended up breaking image files). So: does this make sense as an approach? Or does Editorconfig have no bearing on line-ending handling best practice?