Fix problem with line endings not being normalised when cloning a fresh copy of JUNG

[jbduncan]

In #236, @wumpz reported a problem where, if I understand correctly, Spotless and Git don't agree on what sort of line endings they should both use; Git thinks it should use auto line endings, according to our .gitattributes, but Spotless seems to think otherwise?

@wumpz Would you mind either confirming my understanding or clarifying what I've misunderstood?

Regardless, there are two possible solutions that come to mind:

1. Upgrade Spotless to the latest version, in the hope that it recognises GIT_ATTRIBUTES by default.

2. Tell both Git and Spotless to consistently use some sort of line ending, like Unix LF.

[wumpz]

@jbduncan Spotless does very well handle this .gitattribute file. The problem was that my system does not, at least not while cloning. Therefore it cloned a repository with my global line ending settings not taking .gitattibute into account. My solution was to clone the repository by providing git the needed line ending settings. After that all worked.

git clone -c core.autocrlf=true https://github.com/wumpz/jung.git

[jbduncan]

@wumpz Oh ok, cool! Does this mean you're happy for this issue to be closed? Or is there anything you think we could do to prevent this sort of problem in the future?

[wumpz]

For me the problem is solved. Maybe you could update the documentation on cloning the project.

[wumpz]

But maybe another issue. Since my IDE use e.g. four space to indent, every time I want to debug, run I need a spotless:apply to run first, which is a litte anoying.

[wumpz]

@jbduncan IMHO testing linefeeds is problematic. May be you could consider this again. E.g. are you sure, that if you make a travis build, this will work, that travis takes this setting into account?

[jbduncan]

Sorry @wumpz, I'm a bit lost. Would you mind clarifying for me what you mean by "testing linefeeds" and by what setting you're referring to? 🤔

[jbduncan]

Responding to your comment about spotless:apply, yep I agree it's annoying. I don't have a great solution though. I don't know which command you're using to run the tests and other checks, but assuming that you're using mvn clean verify, you can use mvn clean spotless:apply verify, which will automatically format the code for you as you work on things.

I hope this helps!

[jbduncan]

If, alternatively, you're using IntelliJ's debugger to debug the tests, then I admit it comes as a surprise to me that you need to manually run mvn spotless:apply beforehand, as I was under the impression that IntelliJ doesn't delegate things to Maven by default.

(I use Gradle a lot more than Maven, so my knowledge of using Maven inside IntelliJ is lacking.)

I'm finding it hard to think of a solution to this particular problem. Sorry. :(

[wumpz]

@jbduncan "testing linefeeds" means that it is checked using spotless on the client. Now we have git, which corrects linefeeds depending on your settings (e.g. https://stackoverflow.com/questions/10418975/how-to-change-line-ending-settings).
As I understand it, you are setting with text=auto therefore git is responsible for linefeed transformation / correction. So I am not sure, what linefeeds are used doing a clone on a linux computer. Is spotless aware of that?
Regarding the spotless:apply stuff, I will change my format settings as near to the specification spotless has. So maybe I am getting rid of this problems.

[jbduncan]

@wumpz

@jbduncan "testing linefeeds" means that it is checked using spotless on the client.

Ahh okay, thanks for clarifying! I'd forgotten that the Spotless setup I created for JUNG also affects line endings.

JUNG's Spotless config uses google-java-format under the hood, and I was under the impression that google-java-format uses the default line separator for the OS it's running on, which, if I've understood your problem correctly, should make things so that you don't have this strange line separator problem in the first place. 😕

I used my macOS machine just now to test and confirm this, which uses LF line separators by default, so are you by any chance using Windows or some other OS that uses CRLF instead?

Regardless, I now feel more invested in resolving this problem w.r.t. the unexpected line separators upon Git clone, so I wondered if you could give me some instructions so that I can reproduce it? (If you could, then it would allow me to better evaluate if what we need is a documentation fix or some kind of code fix. But if not, then I'd completely understand. 😄)

[wumpz]

@jbduncan I am using a windows system. My global git settings are:

[core]
autocrlf = input

from git documentation:

If you’re on a Linux or macOS system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

IMHO this is the recommended setting for multi os clients (meaning IDs running on windows, max, linux, ...).

I think, thats why spotless got confused, because the linefeeds are linux like checked out and edited on my machine.

[jrtom]

@jbduncan I'm going to assume you've got this one; LMK if you need anything from me.

(And thanks to both of you for continuing to follow up and get this resolved. :) )