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
Currently, text files (java, etc) use a different line endings (CR/CRLF), and some files contain a mix of both.
Working on #1121, I have trouble setting up spotless. The tool always tries to reformat nearly half of the codebase :-)
For java files, there are ~800 out of 1300 files using CRLF style.
Typically the convention is to use LF in the git repo and let git automatically decide on checkout depending on the target platform.
My recommendation would be to use text=auto feature in .gitattributes file to enable automatic conversion. However, this does not help for the files in the repo using CRLF format. It would require a huge commit fixing all the files, and basically rendering "git blame" useless, as this would always point to this commit. I see not other option, as rewriting the commit history is not a good way for a public repo anyway.
@holgerfriedrich line endings and messing with git are not my forte, unfortunately. I suggest you join the discord (https://discord.gg/AfScp5x8r5) to talk with the more experienced developers or ping them here (supertick, kwatters, etc.)
Currently, text files (java, etc) use a different line endings (CR/CRLF), and some files contain a mix of both.
Working on #1121, I have trouble setting up spotless. The tool always tries to reformat nearly half of the codebase :-)
For java files, there are ~800 out of 1300 files using CRLF style.
Typically the convention is to use LF in the git repo and let git automatically decide on checkout depending on the target platform.
My recommendation would be to use
text=auto
feature in.gitattributes
file to enable automatic conversion. However, this does not help for the files in the repo using CRLF format. It would require a huge commit fixing all the files, and basically rendering "git blame" useless, as this would always point to this commit. I see not other option, as rewriting the commit history is not a good way for a public repo anyway.Any ideas on this, @AutonomicPerfectionist ?
The text was updated successfully, but these errors were encountered: