Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
9.0
-
None
-
None
Description
I spend the whole afternoon to figure out why checking sportless and after that applying spotless changes, the results can't be committed (git says, only new line changes, although ly local repo is configured NOT to apply line ending normalization).
I was looking at the top-level git attributes config and did not find any problem. After 3 hours searching and trying I figured out why my local changes were not applied:
In Solr's folder is another .gitattributes file, which sets autodetection for all files, except some types like shell scripts or windows batch files. This will autodetect text files and configure them to use local line endings, which is bad!
On the other hand, spotless is configured to emit and test for linefeed only (UNIX). When you check spotless on a windows checkout it will find a violation in every Java file!
In Lucene we do not have the problem, because Git is configured to only apply "lf" line endings and spotless writes using lf.
We should change one of this:
- enforce "LF" (Unix line endings for all files) - except batch files. I already did this in a commit for *.java files. Ideally we should do this for all text files and people should configure their IDE.
- reconfigure spotless to recognize the GIT attributes settings (this can be configured and is the default).
In addition, we should merge the gitattributes files and only have one top-level. The one in solr/ subfolder is a relic from Lucene/Solr combined repository. This bad setup made debugging very hard and I spent several hours to figure out why this happeded.