Community
Participate
Working Groups
For the "Synchronize" view and the compare editor, there should be either an option to ignore "unimportant" diffs, like different line endings or tabs vs spaces or the views should honor the "autocrlf" Git configuration option. In example with "autocrlf = input", the repository is kept clean of Windows line endings. The local file, created with Windows line endings (the internal Eclipse files like .project in example), stays unchanged. The "Synchronize" view is nonetheless showing those files as "outgoing change".
As for the Compare Editor I think "Ignore White Space" action, available in the context menu, does the job.
Try the 2.0 nightly that honors the core.autocrlf setting.
Is this still an issue?
Even with 2.0.0 (2.0.0.201205312317), the "Synchronize" view is still showing outgoing changes for .project files and similar where the "git status" reports all clean.
There is a workaround: "windows | preferences | general | Compare/Patch | Ignore white space" also apparently ignores line-ending mismatches, but if you desire to see the whitespace *and* ignore line-ending the you are SOL. So it is still an issue for me on windows 7, eclipse 4.2 (juno) and egit/jgit 2.0.0.201206120900-r and windows xp sp3 also in eclipse 3.7.2 (indigo), in that if I go to compare/patch settings under windows|preferences|general there is no option to ignore line endings, separate from ignore whitespace. This is also a popular issue among windows users. Please see this forum thread. http://www.eclipse.org/forums/index.php/m/899896/#msg_899896
Ignoring line endings (and not other whitespace), I think would be better off being implemented in the org.eclipse.compare packages. Any version control system has an issue here.
I tend to agree with the last comment. We should not see line ending changes at all in the first place if the autocrlf option is fully respected by all the tools manipulating the files. I pointed out in the forum in http://www.eclipse.org/forums/index.php/mv/msg/366456/896455/#msg_896455 that it appears that Egit itself ends up introducing such changes. It would seem best to focus on root causes for inconsistent line endings...
I'll suggest this goes to Platform/Compare as a feature request then.
(In reply to comment #6) > Ignoring line endings (and not other whitespace), I think would be better > off being implemented in the org.eclipse.compare packages. Any version > control system has an issue here. FWIW, I tend to disagree. The line-ending magic is specific to version control systems. Some implement some magic others don't. In any case, such a magic must ensure that the proper input is fed into the compare view. Otherwise it looks like the compare view must be "hacked" to work around line-ending issues generated by version control systems. In terms of Git/EGit I'd expect that EGit apply any autocrlf magic before the content is passed to the compare view. Thus, when comparing a file in the "working copy" with a file from the index then any line-ending conversions must be applied before the compare view gets the content. But that's just how I'd implement it. Note, this doesn't mean that the feature request is invalid. It's still valuable to have such an option in a good compare viewer/editor. I just don't think it's a good solution to the EGit autocrlf issues.
Due to the wording of the issue I think it should stay here, but I change importance to feature request (forgot that when I reassigned) and open Bug 387501.
I'd just like to add my voice to this. Line endings are dependent on a number of things, e.g. operating system, editor, supplier etc so should be considered as a special case of whitespace and therefore have a separate ignore option. There are cases where you might not care how lines finish (as your revision control system is configured to manage line endings for example), but you do care about having tab characters in the code instead of spaces.
Having the option in the platform also solves the problem with Compare with each other, where version control is not involved.
Can we kindly get an update on this? It is rather hair pulling exercise on a large projects spanning different operating systems and teams; so much that I have resorted to using SourceTree.
This makes create patch option useless.
Created attachment 262953 [details] Totally maddening, all these files show up in the file list due to line endings difference only.
Created a(In reply to Gunnar Wagenknecht from comment #9) ... > In terms of Git/EGit I'd expect that EGit apply any autocrlf magic before > the content is passed to the compare view. Thus, when comparing a file in > the "working copy" with a file from the index then any line-ending > conversions must be applied before the compare view gets the content. But > that's just how I'd implement it. > > Note, this doesn't mean that the feature request is invalid. It's still > valuable to have such an option in a good compare viewer/editor. I just > don't think it's a good solution to the EGit autocrlf issues. Created a sister Bug 497439: https://bugs.eclipse.org/bugs/show_bug.cgi?id=497439
