Community
Participate
Working Groups
Eclipse SDK Version: 3.7.0 Build id: I20110104-0920 EGit Version: 0.10.1 Steps: 1) I have MSGit installed, I cloned http://git.eclipse.org/gitroot/e4/org.eclipse.orion.server.git using Git Bash 2) Imported projects from the cloned repo to my workspace using 'Import > General > Existing Project into Workspace' 3) Shared one of added projects using 'Team > Share > Git' 4) I did not change anything in the project and did 'Team > Synchronize' See that all files and folders are shown in Sync View. The difference is whitespace characters. When I do 'git status' in Git Bash it shows nothing to commit.
5) When starting the sync "Include local uncommitted changes" option has been checked
Bumping up the severity since Sync View for Git in this particular case is useless.
Issue with line endings was discussed on EGit mailing list, you can find this thread here: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg01731.html
(In reply to comment #2) Szymon, can you check solution suggested in this email: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg01738.html This is rather problem of Git configuration not a issue in EGit Synchronize View
ping, any update here ?
I'm having the same problem... "git diff" is ok, but the Synchronize view is not handling autocrlf and is displaying differences only in end-of-line characters. Note that I want to have autocrlf set as True.
Eclipse 3.7.1 Build id: M20110909-1335 EGit 1.3.0.201202151440-r Cloned a new project, imported, shared. Using Synchronize shows all files as being 'changed locally'. Using "git status" shows no local changes. Checked configuration and core.autoclrf=true.
I've also witnessed this on several occasions as well. Very annoying to deal with synchronizing workspaces. I always find myself reverting back to native git to see true changes and not just files that differ by a space or two.
(In reply to comment #7) > Eclipse 3.7.1 > Build id: M20110909-1335 > > EGit 1.3.0.201202151440-r > > Cloned a new project, imported, shared. > > Using Synchronize shows all files as being 'changed locally'. > Using "git status" shows no local changes. > > Checked configuration and core.autoclrf=true. I fixed this by blowing out all of my files from my .git maintained location and using the .git to recreate my project. (Hard Reset)
Can you validate this report against the 2.0 snapshot?
There is another corner case in which synchronize view could show files as changed when there are no changes in files content. Git apart from saving file deltas also have information about file mode (access rights) and when eg. execution flag was added/removed such change will appear in synchronize view. This is because jgit implementation don't ignore file access modifications, I'll provide a fix that would explicitly ignore files that have same sha-1 in working tree and repository
(In reply to comment #11) > There is another corner case in which synchronize view could show files as > changed when there are no changes in files content. Git apart from saving file > deltas also have information about file mode (access rights) and when eg. > execution flag was added/removed such change will appear in synchronize view. > This is because jgit implementation don't ignore file access modifications, > I'll provide a fix that would explicitly ignore files that have same sha-1 in > working tree and repository Shouldn't this be controlled by core.filemode? Only when false differences should be ignored.
(In reply to comment #12) > (In reply to comment #11) > Shouldn't this be controlled by core.filemode? Only when false differences > should > be ignored. Yes Robin, you are right. The TreeFilter.ANY_DIFF which is used in synchronize view should be aware of repository configuration, especially about mentioned core.filemode. I'll open separeate bug for this and provide a patch.
I've proposed, a fix https://git.eclipse.org/r/5755 with depends on another jgit change that allow read repository configuration for core.filemode option, and based on this configuration ignores or respect changes in file mode. We should also discuss how changes in filemode should be presented in synchronize view. Just listing them without any additional information is counterproductive.
Is this still an issue?
merged as 95a23af59bb8edbc3e20dcf65dd4b1b0e9103132
