Re-normalize line-endings in git of all files to Linux style ("\n")

[HannesWell]

Some ASCII-files were checked-in into git having windows style line endings (\r\n). This is in general not wanted because it can cause modified files without any difference in git-staging.

This change re-normalizes all such files in this repository except for *.bat files which are only used on Windows.

To re-normalize line endings of all files use the following command (including dot):
git add --renormalize .

[LorenzoBettini]

I'm wondering how such files ended up in the Git repository with Windows EOLs in the first place. By having a quick look, from what I recall, the original authors have always used a macOS machine and never a Windows machine. @cdietrich @szarnekow do you have a clue?

Are we OK to merge this?

[LorenzoBettini]

@HannesWell, another curiosity, especially related to #2976 (comment)

Do you use a Windows machine?
I don't remember having problems with many changes when committing to the Xtext code base; I'm using Linux (or macOS). Maybe I never modified the source code involved in this PR.

Again, it's just to understand why this problem has always been noticed.

[HannesWell]

I'm wondering how such files ended up in the Git repository with Windows EOLs in the first place. By having a quick look, from what I recall, the original authors have always used a macOS machine and never a Windows machine.

I cannot give you a definite answer and the causes are probably multifarious. But looking at the git-history of some files I see different authors that either checked in some files with windows line-endings or converted the entire file from linux- to windows-style. Having Show whitespace characters enabled in the context menu shows you the new-line symbols even in the Git-History view. For example

• org.eclipse.xtend.maven.plugin/src/test/resources/it/compile/multisources-to-link/pom.xml has been checked in by you with Windows line-endings in 31e195c last year. But only that file, the other files in this commit have Linux-style.
• OperationHistoryListener has been converted from Linx- to Windows-style by Sebastian in 2011

Do you use a Windows machine?
I don't remember having problems with many changes when committing to the Xtext code base; I'm using Linux (or macOS). Maybe I never modified the source code involved in this PR.

Yes I'm on Windows.
The problem is usually not Windows alone but in combination with the git config core.autocrlf = true. That config automatically converts the line-endings of text-files to linux-style while committing and to windows-style when checking out files from git. This way text-files are in git with linux-style line-endings while they have windows style when checkout locally. This avoids line-ending edit-wars if the developers of a project use Windows and linux since text-editors at least sometimes tend to change the line-endings to the default of the platform.
It's therefore quite useful and for example Oomph's git-checkout task sets it by default on Windows.

But if a file is actually checked in with Windows-Style line-ending the conversion to linux-style due to autocrlf during committing changes the entire file on the next commit. Git doesn't consider that the file had Windows line-endings before.
That is what happened in #2976 (comment).

The exact behavior of autocrlf can be fine tuned using .gitattributes and it is possible to ensure that the Windows-Style line-ending of certain files is always preserved.

[cdietrich]

Thx

[szarnekow]

Thanks for catching and fixing this, @HannesWell

[LorenzoBettini]

Thanks @HannesWell

I have the correct version of autocrlf in Windows (true) and in Linux/macOS (input).
I'm sure I never did commits from a Windows machine... I can only think that I copied the POM you're mentioning from another POM in the same project; that POM already had crlf and since in Linux the eol is kept (input) I committed with the wrong eols.
crlf for Git is really a nightmare ;)