| Summary: | Deleting project from unrelated repo causes IAE or NPE | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Dani Megert <daniel_megert> | ||||
| Component: | Core | Assignee: | Project Inbox <egit.core-inbox> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | dariusz.luksza, markus.kell.r, matthias.sohn, phil, robin, sam.davis, tomasz.zarna | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dani Megert
Created attachment 215315 [details]
Picture of corrupt paths
Restarting Eclipse does not fix the problem. This is very annoying. Even deleting a simple unshared project triggers this bug. Is there a way to reset the index? I tried hard reset from origin/master, but no luck. This happens with every repo and can be easily reproduced: 0. start with fresh workspace using 3.8 M7 + latest EGit 1. clone 'ssh://git.eclipse.org/gitroot/jgit/jgit.git' 2. import project 'org.eclipse.jgit' 3. create new Java project 'p' 4. delete project 'p' ==> exception If you don't get the exception, simply repeat step 3 and 4 again. Note that sometimes one gets an NPE instead of the IAE: java.lang.NullPointerException at org.eclipse.jgit.treewalk.filter.PathFilter.create(PathFilter.java:77) at org.eclipse.jgit.treewalk.filter.PathFilterGroup.createFromStrings(PathFilterGroup.java:90) at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry.calcIndexDiffData(IndexDiffCacheEntry.java:308) at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry.access$8(IndexDiffCacheEntry.java:296) at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry$6.run(IndexDiffCacheEntry.java:262) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) I can see how this can break since null and empty strings aren't checked for before creating the PathFilterGroup but I'm having trouble reproducing it with your instructions on 3.8 M7 > but I'm having trouble reproducing it with your instructions on 3.8 M7
I always get the NPE. Maybe it matters where the workspace and git directories are? I e.g. have the workspace at C:\e\w\runtime-head-CLEAN and the Git repo at C:\Users\mkl\git\jgit\.git
Analysis:
I set a breakpoint in GitResourceDeltaVisitor#visit(IResourceDelta) and saw that e.g. file "/p/.classpath" was processed there. The bug is that RepositoryMapping.getMapping(resource) wrongly returns the git project there.
RepositoryMapping.getMappingForNonWorkspaceResource(IResource) line: 284
is wrong: It takes a workspace-relative path (fullPath) and calls makeRelativeTo with a file-system path as argument (workingTree).
Yeah, I think you are right, getMappingForNonWorkspaceResource is the problem area. RepositoryMapping#getRepoRelativePath(IResource) makes the same confusion between filesystem locations and workspace paths. The whole https://git.eclipse.org/r/#/c/4653/ looks fishy. Okay, I spun up a Windows VM and was able to reproduce it easily. I did not originally think this was going to be an OS-specific problem so I initially only tried on Linux. Thanks for this bug! It helped me spot down and fix a severe error in the text editor framework (bug 379093). If you get strange exceptions while debugging this, they should be gone with the next I-build. So, in order to fix this: What is the recommended way to a get an absolute file-system path given an IResource that may or may not exist? (In reply to comment #11) > So, in order to fix this: What is the recommended way to a get an absolute > file-system path given an IResource that may or may not exist? IResource#getLocation() is the best you can get. Its API tells when it's applicable. By definition, an IResource is a handle for a file/folder/project in the workspace. The "NonWorkspaceResource" in RepositoryMapping#getMappingForNonWorkspaceResource(IResource) is an oxymoron and sounds like EGit tries to abuse IResource for something that is is not an IResource. There's no support for that in the platform. If you have to deal with file-system paths, then you have to use an IPath or a java.io.File. Dariusz/Matthias, what was the scenario you tried to solve with https://git.eclipse.org/r/#/c/4653/ ? Can we revert that commit? (In reply to comment #12) > By definition, an IResource is a handle for a file/folder/project in the > workspace. The "NonWorkspaceResource" in > RepositoryMapping#getMappingForNonWorkspaceResource(IResource) is an > oxymoron and sounds like EGit tries to abuse IResource for something that is > is not an IResource. There's no support for that in the platform. If you > have to deal with file-system paths, then you have to use an IPath or a > java.io.File. Or EFS (IFileStore) to be independent of a specific file system. (In reply to comment #13) > Or EFS (IFileStore) to be independent of a specific file system. In general, yes. But AFAIK, JGit is not EFS-aware and only works with the operating system's file system, so EFS is probably not part of the game here. (In reply to comment #12) > Dariusz/Matthias, what was the scenario you tried to solve with > https://git.eclipse.org/r/#/c/4653/ ? Can we revert that commit? AFAIR change #4653 was part of partial stating in compare editors. With this change partial staging can be done for non-workspace files. This rather a dirty hack then a proper solution. We still doesn't have proper clean solution for non-workspace-files problem. One idea was to import everything in git repository as a hidden eclipse project, but I'm not so sure if this proper way of solving this issue. (In reply to comment #9) > Okay, I spun up a Windows VM and was able to reproduce it easily. > > I did not originally think this was going to be an OS-specific problem so I > initially only tried on Linux. I am encountering the same problem with some regularity on Linux. If I switch branches in the shell, I frequently get this alert from Eclipse about some other project's re-indexing problem, with "Empty path not permitted". Eclipse IDE for C/C++ Developers Version: Juno Release Build id: 20120614-1722 $ uname -a Linux ipsn-lnx-hordp 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Let me know if you need more details. Pushed a change to attempt to fix this (don't handle non-existing IResource in RepositoryMapping, use IPath where necessary): https://git.eclipse.org/r/7564 (Also change Product to EGit.) So, anyone up for reviewing the change? *** Bug 384987 has been marked as a duplicate of this bug. *** merged as 7abfdb72dfeb935af937be2911b1fb395906b136 Verified in 2.2.0.201211220013. |