Bugzilla – Full Text Bug Listing
| Summary: | Propagate label decorations up to the working set | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Laurent Goubet <laurent.goubet> | ||||
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | b.muskalla, jens.baumgart, markus.duft, markus.kell.r, robin | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.3 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Might be related to bug 343597 has it requires EGit to take ResourceMappings into account for decoration. Created attachment 194914 [details]
Screenshot of a non-propagated decorator
Seems like I failed at attaching the screenshot ...
this is not only an enhancement, but for bigger projects, this is actually a must-have :) with > 700 plugins in the workspace, things get messy otherwise. with > 100 plugin per workings set, it's no longer trivial to find changes other then looking into every single working set (a pain), or pressing commit to see what egit would want to commit (a pain too, since the re-indexing part takes ~1 minute), or rely on the staging view (a pain too, since the staging view re-indexes all the time, and the same timings hold as for the commit dialog...). i did some work on this, which can be reviewed here: http://egit.eclipse.org/r/#change,4970 Merged as 9320b32ea7758d3f14203756607f646d870a2e7e Nice, thanks! I filed bug 369969 to request more text decorations on working sets that contain projects. |
Label decorations for eGit are only displayed for IResources : file, directory, project. With complex workspace, we usually define WorkingSets in order to separate our projects in meaningful groups (EGit, JGit, Acceleo, GUI, Tests...). CVS did a great job at decorating these working sets, allowing us to grasp instantly which of our WorkingSets had changed. However, EGit does not (see attached screenshot for a visual description ... much better than any textual explanation :p). Taking a look at the code behind these decorations, the CVSLightweightDecorator gets called to decorate an "org.eclipse.ui.internal.ide.model.WorkingSetResourceMapping" (method ILightweightLabelDecorator#decorate(Object, IDecoration)) while the GitLightweightDecorator is only called for "IResource"... In which case it will never be able to detect that a given working set contains IProjects associated with the Git repository provider. The main difference between CVS (and SVN) decorators and EGit's is their enablement : ------- CVS ------- <extension point="org.eclipse.ui.decorators"> <decorator <!--snip--> <enablement> <objectClass name="org.eclipse.core.resources.mapping.ResourceMapping"/> </enablement> </decorator> </extension> ------------------- ------- Git ------- <extension point="org.eclipse.ui.decorators"> <decorator <!--snip--> <enablement> <objectClass name="org.eclipse.core.resources.IResource"/> </enablement> <!--snip--> </decorator> </extension> ------------------- This decorator on working sets (well, more precisely "on all of the parents") is extremely useful in order not to lose nested modifications for big workspaces, even more so when the workspace mixes projects under different version control systems.