Set default Unix line ends & UTF-8 in Oomphed workspaces

[iloveeclipse]

Follow up on eclipse-jdt/eclipse.jdt.core#1566.

For all platform repos would make sense to set default line ends to LF (Unix) style & encoding UTF-8 in Oomphed workspace preferences.

While I prefer this to be set in each end every project .settings, this would require lot of work compared to changing only few *.setup files, so whoever uses Oomph will immediately follow "best practices".

Here preferences I mean:

[iloveeclipse]

@merks : if you have time, maybe you could do that? It is not urgent, just nice to have.

[merks]

There is interaction between this option and the Git settings used for checking out the clone as well as how the line endings are handled on check-in with that setting; it's very bad to check in windows line endings accidentally. Of course the option is about new text files, not about old/existing ones. One also can't be sure that every tool properly uses the preference (workspace and/or project-specific).

I need to think about this and of course find time for this... One argument against, is that the more we all just set UTF-8 and Unix line endings, the less we will notice that our tools screw things up. E.g., PDE does this when I tell it to Update a location:

It uses both the wrong encoding, i.e., not that specified by the XML file but the system default I expect, and also the wrong linefeed. The Linux and Mac users don't notice this...

[jukzi]

Changing workspace setting would not have helped on the issue, as the mixed line endings have been checked in without using eclipse see eclipse-jdt/eclipse.jdt.core#1566 (comment)
Using the oomphed workspace does already setup git autocrlf

[jukzi]

#1573 (comment)

You could setup a CI job which uses the output of git ls-files --eol to reject files which use unwanted line endings.

that would be sufficient to me

[merks]

Are you sure they are checked it. If I download the file straight from the raw clone view, it looks like this:

With proper linux line endings. Note that in my picture, the thing on the left is the workspace version. This is the only version with some Linux line endings so I still think that the tool always uses \n regards of the file contents and regardless of preferences...