Community
Participate
Working Groups
# Environment - MacOS - Git integration for Eclipse 6.8.0.202310031909 org.eclipse.egit.feature.group Eclipse EGit - Eclipse IDE for Java Developers 2023-12 # Test steps - Install Eclipse IDE for Java Developers 2023-12 - Clone a repository git@github.com:jenkinsci/rich-text-publisher-plugin.git - Import a single Maven project from that repository - Make a random change to pom.xml, save - In Git Staging view - Refresh - Select unstaged pom.xml - Use Compare with Index context menu # Expected result A diff tool editor opens # Actual result 'Git Compare...' has encountered a problem. IO error looking up path /private/tmp/rich-text-publisher-plugin/pom.xml in [RepositoryHandle:Repository[/private/tmp/rich-text-publisher-plugin/.git]]. This is also reproducible on released version of eGit 6.7.0 in Eclipse 2023-09
Cannot reproduce, even if I clone into /private/tmp. But it may have something to do with the fact that /private/tmp is a hidden directory on OS X. But I'm using an old OS X (10.14.6); perhaps the behavior is different on newer OS X.
EGit 6.3 works fine under same conditions. The original problem is reproducible on Eclipse installed in home directory. And with git repository in ~/git. So path is not a problem.
Could EGit add a stack trace in this error message? It is hard to isolate problem without.
cannot reproduce and works without issues for me on MacOS 14.0 using 6.8.0.202309121949 and 6.8.0.202310031909
(In reply to Vasili Gulevich from comment #3) > Could EGit add a stack trace in this error message? It is hard to isolate > problem without. The error message _should_ have a stack trace. But maybe only in the Eclipse error log.
(In reply to Thomas Wolf from comment #5) > (In reply to Vasili Gulevich from comment #3) > > Could EGit add a stack trace in this error message? It is hard to isolate > > problem without. > > The error message _should_ have a stack trace. But maybe only in the Eclipse > error log. It does not,
(In reply to Vasili Gulevich from comment #6) > (In reply to Thomas Wolf from comment #5) > > (In reply to Vasili Gulevich from comment #3) > > > Could EGit add a stack trace in this error message? It is hard to isolate > > > problem without. > > > > The error message _should_ have a stack trace. But maybe only in the Eclipse > > error log. > > It does not, Sounds to me like some workspace corruption. Perhaps missing git data for the project? Is there a file in the workspace metadata at .metadata/.plugins/org.eclipse.core.resources/.projects/rich-text-publisher-plugin/org.eclipse.egit.core/GitProjectData.prefs ? If so, what does it contain? In the package explorer, is the project shown with the git decorations?
(In reply to Thomas Wolf from comment #7) > Is there a file in the workspace metadata at > > > .metadata/.plugins/org.eclipse.core.resources/.projects/rich-text-publisher- > plugin/org.eclipse.egit.core/GitProjectData.prefs > > ? If so, what does it contain? No such file in the workspace: find /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core/.org.eclipse.egit.core.cmp /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core/.org.eclipse.egit.core.cmp/.settings /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core/.org.eclipse.egit.core.cmp/.settings/org.eclipse.core.resources.prefs /Users/vasiligulevich/xored/rich-text-publisher-plugin/ws/jdt/.metadata/.plugins/org.eclipse.egit.core/.org.eclipse.egit.core.cmp/.project > In the package explorer, is the project shown with the git decorations? That's it! Thanks for the hint! The projects are no longer autoshared when they are imported from Git repository with a context menu in Git repositories view!
I've managed to reproduce the problem on eGit 6.3. So the problem is not a regression and can be restated: The error that happens in diff tool when working outside of workspace is confusing.
(In reply to Vasili Gulevich from comment #8) > The projects are no longer autoshared when they are imported from Git > repository with a context menu in Git repositories view! Which leads to the question: why not? That's not normal, and it works for me. But it also explains why you had to refresh the staging view first. (I didn't have to; it updated automatically -- modulo an age-old bug that the newly created .project file doesn't show up initially, but that has nothing to do with your problem here.) (In reply to Vasili Gulevich from comment #9) > I've managed to reproduce the problem on eGit 6.3. > > So the problem is not a regression and can be restated: > > The error that happens in diff tool when working outside of workspace is > confusing. Well, it's not working "outside of workspace". The file is in the Eclipse workspace (present in the package explorer). And it appears in the staging view, so obviously there is a git repository for it, and the file is in the git working tree. I guess there are many places in EGit where it is assumed that if an Eclipse resource can be found for a file in the git working tree, then the Eclipse project is "shared with git" in Eclipse and thus the EGit metadata exists. And if that EGit metadata doesn't exist, things may go wrong. We might consider improving that error message to hint that maybe the Eclipse project is not shared with git. Not sure we can easily and automatically fall back to our "outside of Eclipse workspace" behavior -- that would likely lead to more usability problems later on, since the file actually _is_ in the Eclipse workspace. (Missing automatic Eclipse resource refreshes come to mind.) But maybe that is still a useful way to deal with this situation. Might need more careful checking in the staging view. Another alternative might be to ask the user whether the project should be shared with the git repository, or do so automatically, at the very least if there is a .git repository directly at the project root. But before embarking on that journey, I'd like to get at the bottom of the question above: why is the project not "shared with git" after the import? How _exactly_ do you import the project? Did you uncheck the preference Version Control(Team)->Git->Projects, "Automatically share projects located in a Git repository"? What are the precise steps to reproduce this with Eclipse for Java Developers 2023-09 as shipped (fresh download)?
Created attachment 289199 [details] Git Repositories view Import Projects menu item
(In reply to Thomas Wolf from comment #10) > > The error that happens in diff tool when working outside of workspace is > > confusing. > > Well, it's not working "outside of workspace". The file is in the Eclipse > workspace (present in the package explorer). And it appears in the staging > view, so obviously there is a git repository for it, and the file is in the > git working tree. Yes, I misspoke, thanks. > I guess there are many places in EGit where it is assumed that if an Eclipse > resource can be found for a file in the git working tree, then the Eclipse > project is "shared with git" in Eclipse and thus the EGit metadata exists. > And if that EGit metadata doesn't exist, things may go wrong. > > We might consider improving that error message to hint that maybe the > Eclipse project is not shared with git. Can't eGit check if it is the case and be explicit in the message? > How _exactly_ do you import the project? > Did you uncheck the preference Version Control(Team)->Git->Projects, > "Automatically share projects located in a Git repository"? I did not. Turns out, there is a ~/.eclipse/org.eclipse.oomph.setup/setups/user.setup that got a section: <setupTask xsi:type="setup:CompoundTask" name="org.eclipse.egit.core"> <setupTask xsi:type="setup:PreferenceTask" id="sync1" key="/instance/org.eclipse.egit.core/core_autoShareProjects" value="false"/> </setupTask> this is probably an artifact of Preferences Recording function, which usually does not work, so I've forgot about its existence. In this case it is likely that Preference were set in accordance to this file upon a fresh install of Eclipse. > What are the precise steps to reproduce this with Eclipse for Java > Developers 2023-09 as shipped (fresh download)? The precise steps are in the description (Import menu is shown on a screenshot https://bugs.eclipse.org/bugs/attachment.cgi?id=289199 it is invoked via Git repositories view)
In fact, this is a bug in the StagingViewContentProvider. Will fix soon.
