README.license may be used in packaging, just make sure before…

Ok.. if there's something, it would be closer to the expected line ending to be stored through git (CRLF not being what we would want in git)

Keep in mind that these files are externally svn checked out from the mentioned source code repository.

Is it important to change line endings?

I have no chance to test it locally. Sometimes different ms Windows versions are differently sensitive to such changes.

Keep in mind that these files are externally svn checked out from the mentioned source code repository.

Not SVN anymore, but yes, I'm aware of the repo and plan to upstream the changes too.

Is it important to change line endings?

I have no chance to test it locally. Sometimes different ms Windows versions are differently sensitive to such changes.

It doesn't change them yet here. (In 3 PRs, if all prerequisites are merged). And when it will, it will be to enforce having .bat stored into git as CRLF exactly for that reason, where .bat files are expected to be that way. People checking out files even with core crlf set to lf will still have the .bat files as CRLF (according to the settings in the .gitattributes file).
Same thing goes for cross-compiling, having the .gitattributes set that .bat files to be stored and checked out as CRLF will help as checking out on Linux would have the file with the correct line ending. A similar reason where .sh files are expected to be LF even on windows with the repo checked out as CRLF, .sh should still be LF. And I repeat, it doesn't change it yet. I separated the changes from respecting editorconfig settings regarding trailing white space, from changing whole file's line ending when inconsistent or wrong, so they could be cherry picked separately, as well as git blamed correctly.

Even a older Windows 10 notepad has no problems reading a text file with LF, assuming packaging was done wrong for extra files.

So this PR in particular is really conservative in my opinion, and there's no reason to discuss too much here, there will be other PRs that are better candidates with actual changes. (Thus why taking unimportant changes needing no review out of another PR to prevent stalling the review of the next one).

Other PRs that I considered a preliminary work for getting editorconfig set up for the repo were started in last March, but only one got merged this week. I was still waiting until recently, when the inconveniences of not having editorconfig were starting to be bigger and caused problems, to which I started back the efforts, even if it means having to rebase and solve conflicts. Grass-addons and grass-tutorial will need it too, and I would like it to have similar if not identical .editorconfig files, and a similar CI/precommit config to be easier to maintain.

Can someone with enough permissions proxy the approval?