chore: renormalize line endings in gradlew.bat

[vlsi]

This is a result of running git add . --renormalize: https://stackoverflow.com/a/47580886/1261287

Without this PR, macOS shows gradlew.bat as always modified

[szpak]

I wonder why it affects only Mac, not Linux 🤔 . But maybe it's right ahead of me ;-).

[vlsi]

renormalize is sensitive to the "first git clone".
Have you tried making a fresh clone?
I guess you'll reproduce it then.

[vlsi]

In any case, the flow is the same: one needs to add .gitattributes, and it should go together with renormalize.
I've done that multiple times, and it resolves LF/CRLF issues.

[TWiStErRob]

But then this PR shows that you've changed all CRLF to LF in the repository, how is it going to work on Windows where Batch interpreter cannot handle LF?

[TWiStErRob]

Ok, other than being extremely confused, this is actually necessary. It affects me as well, just didn't see it. When I add the remote and checkout vlsi's branch it works fine, and when re-cloning his fork it also works fine. (I'm on Windows btw.)

[TWiStErRob]

Note: if you download https://raw.githubusercontent.com/vlsi/publish-plugin/renormalize/gradlew.bat, it has LF characters in it.

If you download https://github.com/vlsi/publish-plugin/archive/refs/heads/renormalize.zip, it has CRLF characters correctly.

Is this a bug with the raw endpoint then?

[vlsi]

how is it going to work on Windows where Batch interpreter cannot handle LF?

TLDR: Git converts EOL on checkout. They recommend using core.autocrlf=true with Windows.

Git stores text files in LF format, and it converts them on checkout.
I guess the file was previously stored as "binary" (==CRLF line endings).
As .gitattributes is added, Git understands the file should be stored as LF (in its internal storage) while the file is CRLF, so git shows the diff.

[szpak]

I my other projects, I also use gradlew.bat text eol=crlf with gradlew.bat converted with unix2dos to the crlf format (I didn't know about --normalize) and it works fine. Most likely, importing this project, we missed that step which could cause the aforementioned result.

[TWiStErRob]

Thanks for the info, really helpful!

They recommend using core.autocrlf=true with Windows.

I just had way too many problems with this, some files would be committed with LF some with CRLF, depending on which tool created them. So I just turned it off and rely on whatever is in the repo. IDEA also nicely warns me when I (accidentally) commit CRLF.