Bugzilla – Full Text Bug Listing
| Summary: | files stay in "staged" mode if permissions on project directory have been changed; Commit command reports no changes. | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | James Revillini <james> |
| Component: | Core | Assignee: | Christian Halstrick <christian.halstrick> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antoine, hazen, james, jens.baumgart, leachbj, robin.rosenberg, rprogrammer, stefan.lay |
| Version: | 0.7.1 | ||
| Target Milestone: | 1.0.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
James Revillini
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. |