eclipse.platform.releng.aggregator
eclipse.platform.releng.aggregator copied to clipboard
Set default Unix line ends & UTF-8 in Oomphed workspaces
Follow up on https://github.com/eclipse-jdt/eclipse.jdt.core/pull/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:
@merks : if you have time, maybe you could do that? It is not urgent, just nice to have.
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...
Changing workspace setting would not have helped on the issue, as the mixed line endings have been checked in without using eclipse see https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1566#discussion_r1396690641
Using the oomphed workspace does already setup git autocrlf
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/1573#issuecomment-1825814006
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
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...