You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I think this would also decrease the chance of EFForg/dnt-policy#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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
I happened to notice that multiple Privacy Badger related repositories have a
.editorconfig
which specifiesend_of_line = lf
. However it's possible that individual contributors have git configured to checkout ascrlf
(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
sogit
would always check-out the repository with lf line-endings even on Windows regardless of the contributors git configuration as.gitattributes
takes priority. Optionally agit add --renormalize .
would ensure that all text files are checked into the repository withlf
line endings.See https://git-scm.com/docs/gitattributes#_end_of_line_conversion
I think this would also decrease the chance of EFForg/dnt-policy#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.
The text was updated successfully, but these errors were encountered: