Community
Participate
Working Groups
We have recently committed a change in our project to use version-controlled project-specific settings for the "Text file encoding" and "New text file line delimiter" options in each project's Properties > Resource. We set the "New text file line delimiter" to "Other: Unix" and this change is reflected in the file .settings/org.eclipse.core.runtime.prefs with a new entry: line.separator=\n. In our project many files were created before this change, some on Linux with \n and some on Windows with \r\n. Since the project setting change, when I do Compare With > HEAD Revision on the project, *every* file in the project that has \r\n line delimiters is shown in the Git Tree Compare view, even if the file has not been modified. If I double-click on one of those files, the Compare editor opens up and shows "No Structural Differences". If I do Team > Commit, those files do not show up as modified in the commit dialog. When any of these files is saved, even saved without any changes (e.g. type, delete, save), the file is marked with the Git decorator '>' in the Project Explorer. It seems that internally the line delimiters have changed, even though it does not appear as such with the 'Show Whitespace Characters' option. Committing the file indeed changes the line delimiters. However, if that file is not committed and instead Replace With > HEAD Revision is done, the content of the file is not replaced with the HEAD revision, the local changes to the line delimiter remains in the workspace. Reset > Hard is required to cleanup the unwanted line delimiter change. Also, I am not sure under which circumstance this happens, but sometimes all those files with incorrect line delimiter become marked as changed with the Git decorator '>'.
