Bugzilla – Full Text Bug Listing
| Summary: | Eclipse Projects with certain Project names do not show Git decorations and can not be Added or Committed to repo | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | <h1055071> | ||||||
| Component: | Core | Assignee: | Philipp Thun <philipp.thun> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | awanthika, caniszczyk, manuel.doninger, mathias.kinzler, matthias.sohn, pwebster, robin.rosenberg, stefan.lay | ||||||
| Version: | 0.11 | ||||||||
| Target Milestone: | 0.11-M2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Created attachment 188613 [details]
Test Projects
Here's the three test projects in a "test" folder zipped up.
Further testing shows that it doesn't matter about the project folder names being the same as the project names, as it's the project names that cause this problem. You can name the folders "f1", "f2" and "f3" if you like. This isn't good. However, we should still ship 0.11 with this issues. Workarounds would be cloning via CLI and importing. (In reply to comment #3) > This isn't good. > > However, we should still ship 0.11 with this issues. > > Workarounds would be cloning via CLI and importing. I tested this workaround, and the problem is still there, I'm afraid. One workaround is, if you just select one project from that folder and create the repository. If you then select the other projects and share them, the repository created before is recognized and selected and the projects are correctly shared and decorated. In my eyes this bug has nothing to do with the name of the projects but only with the fact, that we don't recognize a repository, that was created in the same "Share Project Wizard" session. Further testing boils this down to an even simpler case of having only two projects with names "com.foo.project.old" and "com.foo.project.tests.old" C:\test |-----com.foo.project.old |-----com.foo.project.tests.old Select both of these in Package Explorer and do steps 3-5 - no projects at all have got decorations and no "Add" or "Commit" operations are available. I am trying to find a pattern here and the simplest case I can find so far is: 2 projects in sibling folders sharing the same parent folder: Project 1 name Project 2 name Result ---------------------------------------------------- c.f.p.o c.f.p.t.o NOT OK a.b.c.d a.b.c.e.d OK Strange. OK, I've experimented with this all evening and discovered the simplest test case: 1. Create a folder C:\test\f1 2. Create a Java project in that folder with the project name of c.f.p.o 3. In Eclipse Project Explorer select this and choose "Team->Share Project->Git" 4. In the wizard select the project and edit the repo path so that the .git repo is created in the parent "C:\test" folder and click "Create Repository" Result - no decorations and cannot add or commit. Created attachment 188631 [details]
Simpler Test Case
And here is the simpler test case attached.
Another simple test case: Simply create a Java project called "c.f.p.o" (without the quote marks) anywhere you like and then share it and create the git repo in teh wizard in its own folder (default). Result is that there are no decorations in Project Explorer but at least this time you can do an "Add" followed by "Commit". Now try it with a project called "a.b.c.d" (without the quote marks) and everything is fine. So - a project called "c.f.p.o" vs. a project called "a.b.c.d". Strange. Yes, i can confirm that. A project named "a.b.c.d" works perfect, a project named "c.f.p.o" shows the behaviour you described. Very strange. Maybe i have the time to debug that tomorrow evening. Some more tests with project names: Project name Result ---------------------------- a.b.c.d OK c.f.p.q OK d.g.q.p OK m.n.o.p OK f.f.f.f OK c.f.p.o NOT OK w.x.y.z NOT OK c.d.r.o NOT OK I edited the title of this bug to make it accurate. It has nothing to do with Project name prefixes, only certain combinations of letters in a Project name. Hmmm. I debugged this and it seems this is simply working as designed: under Window > Preferences > Team > Ignored Resources, there is are entries telling Eclipse to ignore *.Z and *.o resources. If these are unticked, the projects are decorated fine. (In reply to comment #14) > Hmmm. I debugged this and it seems this is simply working as designed: under > Window > Preferences > Team > Ignored Resources, there is are entries telling > Eclipse to ignore *.Z and *.o resources. If these are unticked, the projects > are decorated fine. Not here. If I create a project called "com.dang.redkite.old" I don't see the decorators, if it's called "com.dang.redkite" I do. (In reply to comment #15) > (In reply to comment #14) > > Hmmm. I debugged this and it seems this is simply working as designed: under > > Window > Preferences > Team > Ignored Resources, there is are entries telling > > Eclipse to ignore *.Z and *.o resources. If these are unticked, the projects > > are decorated fine. > > Not here. If I create a project called "com.dang.redkite.old" I don't see the > decorators, if it's called "com.dang.redkite" I do. In this case, you have to untick the entry ".old" in the ignored resources preference page. (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > Hmmm. I debugged this and it seems this is simply working as designed: under > > > Window > Preferences > Team > Ignored Resources, there is are entries telling > > > Eclipse to ignore *.Z and *.o resources. If these are unticked, the projects > > > are decorated fine. > > > > Not here. If I create a project called "com.dang.redkite.old" I don't see the > > decorators, if it's called "com.dang.redkite" I do. > > In this case, you have to untick the entry ".old" in the ignored resources > preference page. Dang! Yes...it could be the Preferences > Team > Ignored Resources that's cause all this. I'll check this out now. OK, it's as you say because these patterns are set to be ignored in Window > Preferences > Team > Ignored Resources. But I think this is still problem to apply the ignored resources pattern to the project name. This doesn't happen if I share the project with CVS, for example. Surely the Ignored Resources pattern should only be applied to the child files of the Project? (In reply to comment #18) > OK, it's as you say because these patterns are set to be ignored in Window > > Preferences > Team > Ignored Resources. > > But I think this is still problem to apply the ignored resources pattern to the > project name. This doesn't happen if I share the project with CVS, for example. > Surely the Ignored Resources pattern should only be applied to the child files > of the Project? Would the developers consider it a bug/unwanted behaviour that the ignored resources pattern is applied to the project name? This does not happen to the CVS Team provider. Of course, the workaround is to disable the pattern in Window > Preferences > Team > Ignored Resources and add it to a .gitignore file where needed. (In reply to comment #19) > Would the developers consider it a bug/unwanted behaviour that the ignored > resources pattern is applied to the project name? This does not happen to the > CVS Team provider. > > Of course, the workaround is to disable the pattern in Window > Preferences > > Team > Ignored Resources and add it to a .gitignore file where needed. Since the project are imported they are obviously not ignored. So, yes, it's a bug. (In reply to comment #20) > (In reply to comment #19) > > Would the developers consider it a bug/unwanted behaviour that the ignored > > resources pattern is applied to the project name? This does not happen to the > > CVS Team provider. > > > > Of course, the workaround is to disable the pattern in Window > Preferences > > > Team > Ignored Resources and add it to a .gitignore file where needed. > > Since the project are imported they are obviously not ignored. So, yes, it's a > bug. OK, should I rename this bug to a more accurate title or open a new bug? (In reply to comment #21) > OK, should I rename this bug to a more accurate title or open a new bug? No, I think this is an example of a good bug report. The only thing missing is a patch :) Fix proposed at http://egit.eclipse.org/r/#change,2496 (In reply to comment #23) > Fix proposed at > > http://egit.eclipse.org/r/#change,2496 I looked at the code this morning and came up with exactly the same check: if (!(resource instanceof IProject) && Team.isIgnoredHint(resource)) return; Unfortunately, this only takes care of the Project node, the child resources still remain undecorated. (In reply to comment #24) > (In reply to comment #23) > > Fix proposed at > > > > http://egit.eclipse.org/r/#change,2496 > > I looked at the code this morning and came up with exactly the same check: > > if (!(resource instanceof IProject) && Team.isIgnoredHint(resource)) > return; > > Unfortunately, this only takes care of the Project node, the child resources > still remain undecorated. I think that check is part of the solution, though. This is the first time I looked at the EGit code but I also found some clues in DecoratableResourceAdapter. Then I got lost in the code... Fix proposed: http://egit.eclipse.org/r/3001 merged as 6da9779fb769ea50b59e88553ad3bbf604a7c499 |