Spotless always converts the newlines to CRLF in my environment, very annoying -.- Does somebody know how to solve this?
Git core.autocrlf is set to input, although changing it to other values does not affect the behavior. I also tried to add eol=lf to the .gitattributes file, but without any success…
What platform are you using?
Windows 10, IntelliJ IDEA
I have the same problem, had to set core.autocrlf=true to make it work.
Spotless doesn’t properly support autocrlf, so it’ll think that crlf is correct if the os is detected as windows. You can try setting core.eol=lf, the .gitattributes setting is ignored on my system (Win 10), don’t know why. In fact I have to set core.eol=crlf to do a complete build (see OH3: Maven build failing (bad format violations in a POM) · Issue #8712 · openhab/openhab-addons · GitHub)
But why do you want to use lf on a windows machine?
I don’t know a single text editor that does not support LF (even WordPad and Notepad do support it meanwhile!) and I’d like to checkout the code always as-is, e.g. to detect issues with newline format within the remote repository (not necessarily for openHAB, but in general for any projects).
Did you try core.eol=lf?
Ah, that works, thanks! Didn’t try that as the Git docs said it’s overriden by autcrlf.
That’s why it works flawlessly with the opposite (core.eol=crlf) on my system. autorlf=true takes precedence when git is checking what to do, but since spotless does not implement autocrlf it takes the value of eol.
I realize this is an ancient topic, but I wonder whether it is more recent than the docs (see step 5), stating that * text eol=lf should be added. Or is the information in this topic obsolete, and is the documentation (and thus * text eol=lf) correct?
Also, git warns me:
$ git add .
warning: in the working copy of '.gitattributes', CRLF will be replaced by LF the next time Git touches it
warning: in the working copy of 'bundles/org.openhab.binding.shelly/src/main/java/org/openhab/binding/shelly/internal/api2/ShellyBluApi.java', CRLF will be replaced by LF the next time Git touches it
This is the opposite of what is claimed in the documentation…?
Any takers? 