`.editorconfig` specifies `lf` line-endings, but there is no matching `.gitattributes`

[Mikaela]

I happened to notice that multiple Privacy Badger related repositories have a .editorconfig which specifies end_of_line = lf. However it's possible that individual contributors have git configured to checkout as crlf (core.autocrlf) especially in Windows, which may confuse editorconfig capable text editors.

The solution would be adding a .gitattributes file with contents * text=auto eol=lf so git would always check-out the repository with lf line-endings even on Windows regardless of the contributors git configuration as .gitattributes takes priority. Optionally a git add --renormalize . would ensure that all text files are checked into the repository with lf line endings.

See https://git-scm.com/docs/gitattributes#_end_of_line_conversion

I think this would also decrease the chance of https://github.com/EFForg/dnt-policy/issues/22 happening at least when the repository is cloned with git.

I opened this issue instead of a PR, because in addition to being unsure of whether this is considered a problem, I think opening identical pull requests towards multiple repositories would be considered as spam especially out of the blue without any explanation.

[ghostwords]

Thanks for raising this issue and thank you for your thoughtfulness!

However it's possible that individual contributors have git configured to checkout as crlf (core.autocrlf) especially in Windows, which may confuse editorconfig capable text editors.

What will happen in this scenario? I'm trying to understand the problem.

[Mikaela]

I don't know how intelligent text editors are, but I think showing line endings in wrong way is a possibility or maybe they would write mixed crlf and lf line endings onto the file.

I think the worst case scenario would be git diff claiming that every line was removed and then added again. I was trying to find a link that would demonstrate the issue, but I didn't find an exact case while these seem the most relevant:

• https://luispuerto.net/blog/2020/01/04/normalize-line-endings-files-git/
• https://stackoverflow.com/q/39076854 - this shows the changed file issue a bit
• https://stackoverflow.com/q/2517190 - here multiple users suggest the same eol=lf

[ghostwords]

Got it, thanks!

I also got a bit more context by visiting some high profile EditorConfig users. Looks like having a well-configured .gitattributes file is best practice if your project wants to support Windows contributors.