Community
Participate
Working Groups
Build Identifier: Aptana Studio, build: 2.0.4.1268158907, EGit 0.7.1 If a user is working on a project which uses EGit and the permissions are changed on the files, the Team > Commit command will not check in the permission changes to the files, but will check in changes to the content of the files. The result is that the project tree will continually show the files as having staged changes, but will not check them in. Reproducible: Always Steps to Reproduce: 1. Open Aptana or Eclipse 2. Right-click "Projects" in Project Explorer > New > Project ... 3. Select a General project, click Next 4. enter Project name as "foo" 5. click Finish 6. right-click the "foo" project folder > Team > Share Project ... 7. In Configure Git Repository dialog, select the foo project, click "Create Repository", then click "Finish". 8. Right click the "foo" project folder > New > File 9. In the New File dialog box, type "bar" as the file name. (the "bar" file opens in editor) 10. Right click the "bar" file > Team > Add to Version Control (the "bar" file marker goes to "added") 11. Right click the "bar" file > Team > Commit 12. In the Commit dialog, enter "initial commit of bar", then click Commit. 13. Open a terminal 14. cd ~/workspace (cd to the Eclipse workspace directory. I'll assume it's ~/workspace.) 16. chmod -R 766 foo 17. Go back to Aptana or Eclipse 18. In the editor pane for "bar", type "baz" and save the file. (the marker should go to "dirty") 19. Right-click the "bar" file > Team > Commit 20. For a commit comment enter "Here's where it gets weird." and click "Commit". EXPECTED: the "bar" file should now show the "tracked" icon. WHAT HAPPENS: the "bar" file has the "staged" icon on it. Also, trying to commit "bar" now yields the following dialog "No changed items were selected. Would you like to amend the last commit?" WORKAROUND STEPS: 1. go back to terminal 2. navigate to the "foo" project folder 3. git commit -a -m "trying to get EGit back on track" 4. go back into Aptana or Eclipse and you're back to the happy yellow cans.
I can confirm, and the workaround works.
Actually, workaround only works until the next commit. Next commit shows (without decorations) all the files that previously had non-644 permissions, even if they now actually have mode 644 in the filesystem, as "Mod., unstaged". After that commit, they all now show the staged decoration and we're back to square one. I have tried refreshing (through eclipse, egit, and native git (update-index)). A difference between mine and James' situation may be that, some time after I committed the files of "changed mode" 755 (which was actually the original mode), I changed most of them to 644 in the filesystem to be like the rest of the files. This is very annoying, since it causes that group of files to not be committed unless I use native git before each egit commit and egit commits take about half a minute, even for one real file change.
Found a workaround. Original bug (seems to be closely related if not same as 312164): 1. Create project with some files set to mode 755 2. "Share" project, creating a new git repository. 3. Add files (including the 755's) to version control 4. Make initial commit 5. Some files are staged and refuse to be committed 6. Commit manually with native git 7. egit will auto-refresh and show they are sync'ed --Now it differs from the main bug-- 8. Quit Eclipse 9. Change mode to 644 (which appears to be what it counts as "original") 10. Start Eclipse 11. Refresh containing project 12. Make some minor change that will warrant a commit 13. Commit + The commit dialog shows all files that were originally 755 as modified entries in the commit. 14. Now all the files originally 755 show staged again, and again refuse to be committed. Note: The commit (even in native git) shows 'mode changed to 755' both after it was added (but not changed) and after it was changed to 644. Expected: a) After original commit, the files shouldn't show a modification since they originally had mode 755. b) After refresh, it should recognize the files as having mode 644, not mode 755. Workaround: After changing to 644, remove each file (or a directory tree it is under) from version control, then add them back (without committing between). This causes them to show 'tracked' and remain such, even after further commits and restarts of Eclipse. Note that removing the project from version control and re-adding it does not achieve this effect. Neither does disconnecting the project and re-sharing it. Setup: Eclipse SDK Version: 3.5.2 Build id: M20100211-1343 Eclipse EGit Feature (Incubation) 0.7.1 org.eclipse.egit.feature.group
Is this the same as 307560?
> Is this the same as 307560? Looks like it is. Sorry, I searched for it but didn't come across that one. Maybe this can be closed, but referenced from the other since it has the benefit of the steps to reproduce and workaround steps.
Another workaround : If you don't bother about file permission in your repository you can add [core] filemode = false in your .gitconfig file (I did it thru the eclipse git preference since it didn't took it into account when I added it by hand in the file) My Egit eclipse commit now work perfectly : no * in Eclipse and git status in CLI shows nothing to commit. the only counterpart is that my permission are not send to the repo but for my project I don't care. Hope it Helps Antoine Sabot-Durand twitter : @antoine_sd
(In reply to comment #6) > Another workaround : > [core] > filemode = false I tried this setting. I have a simple project containing a single script file (permissions 755) and all other files/dirs have permissions 644/755, respectively. Command line git status shows clean working directory, but EGit decorates script as "dirty" in Package Explorer. Parent directories of script file are also decorated "dirty". OS: Win7 x64 Java: Oracle JDK 1.6.0_21 (32-bit) Eclipse Version: Helios Service Release 1 Eclipse Build id: 20100917-0705 Eclipse EGit: 0.10.0.201011231519
(In reply to comment #6) > Another workaround : > > If you don't bother about file permission in your repository you can add > > [core] > filemode = false > That work around works for me. From a brief look through the code a number of JVMs don't support fetching the executable bit - in this case egit will mark any executable file as modified (JDK1.6 should support it but JDK1.5 doesnt). If the JVM doesn't support detection of the executable bit then shouldn't egit use filemode=false instead of marking these as modified?
Please try out again with the latest nightly build. Bug 307560 which is probably caused by the same problem was solved now - so I hope this problem is also solved now.
I assume the problem no longer occurs. Please reopen the message otherwise.
