Community
Participate
Working Groups
Build Identifier: I20100413-1521 Many of the operations on (Java) projects make sense on the entire working set. Currently, there are no git actions available for a working set. If you block-select all the projects inside the working set, then many (all?) of the actions are available. This is the expected behaviour. Motivation: Maven multi-module projects create one Eclipse project for each subproject, and they'll all normally be stored in the same git repo (with the parent pom in the root). Subclipse allows this, too. Reproducible: Always Steps to Reproduce: 1. Add two or more git-enabled projects to a Java working set in the Java Package Explorer. 2. Right click it -> Team -> ... 3. Observe "Apply patch.." being the only action.
*** Bug 324366 has been marked as a duplicate of this bug. ***
Working sets could also show repository and branch annotations (as cvs does).
0.8.0 has already passed. Mykola please update the Target Milestone if you're still planning to work on this, or close the bug if it's already fixed.
[Batch change] Remove passed Target Milestones If anyone on CC list is going to fix/implement this, feel free to assign a new, post-1.3/2.0, target milestone.
Note that the Git toolbar actions can operate on a working set (Window -> Customize Perspective... -> Command Groups Availability -> check Git). Changed title to reflect that this means the team context menu actions now. Repository and branch decorations have been implemented on the working set in the meantime.
This should be possible by extending the visibleWhen definitions in plugin.xml. For testing whether the org.eclipse.ui.IWorkingSet contains projects that are all shared in the same repository, a new org.eclipse.core.expressions.propertyTesters is probably necessary.
Created attachment 239335 [details] The actual context menu on the working set (no git actions)
Created attachment 239338 [details] The actual context menu on a multiple projects selection (with git actions)
It would be great having this feature especially when you have dozens of subprojects (nested) under a master project: they share the same git repository and you often need to operate on all of them. IMHO the expected behavior is the same as when you select multiple projects with git enabled. I've just attached a couple of screenshots in order to reduce the possibility of misunderstandings.
(In reply to Davide Cavestro from comment #9) > It would be great having this feature especially when you have dozens of > subprojects (nested) under a master project: they share the same git > repository and you often need to operate on all of them. > IMHO the expected behavior is the same as when you select multiple projects > with git enabled. This makes sense if all projects in a working set are versioned in the same repository and this should be simple to implement. If projects under a working set are versioned in multiple repositories common git menu entries on the working set seem not really useful.
Yes, of course, it would be useful to apply actions if all the projects in the working set use EGit. Or, at least, to apply actions on all of those projects in the working set that use EGit (skipping any other one).
(In reply to Mauro Molinari from comment #11) > Yes, of course, it would be useful to apply actions if all the projects in > the working set use EGit. Or, at least, to apply actions on all of those > projects in the working set that use EGit (skipping any other one). it's not only that all the projects in a working set should use EGit but also be versioned in the same git repository otherwise this could become pretty complex. E.g. how would you implement rebase across projects being versioned in different repositories ?
(In reply to Matthias Sohn from comment #12) > it's not only that all the projects in a working set should use EGit but > also be versioned in the same git repository otherwise this could become > pretty complex. E.g. how would you implement rebase across projects being > versioned in different repositories ? Certain actions may become too complex to work on mixed repositories, however others (like Update, for instance) don't. In any case, what it is expected here is to have the useful features that Subversive, for instance, gives you on a working set for projects shared in a SVN repository. And, if I remember well, the same Eclipse CVS plugin.
(In reply to Mauro Molinari from comment #13) > (In reply to Matthias Sohn from comment #12) > > it's not only that all the projects in a working set should use EGit but > > also be versioned in the same git repository otherwise this could become > > pretty complex. E.g. how would you implement rebase across projects being > > versioned in different repositories ? > > Certain actions may become too complex to work on mixed repositories, > however others (like Update, for instance) don't. > In any case, what it is expected here is to have the useful features that > Subversive, for instance, gives you on a working set for projects shared in > a SVN repository. And, if I remember well, the same Eclipse CVS plugin. +1
(In reply to Mauro Molinari from comment #13) > (In reply to Matthias Sohn from comment #12) > > it's not only that all the projects in a working set should use EGit but > > also be versioned in the same git repository otherwise this could become > > pretty complex. E.g. how would you implement rebase across projects being > > versioned in different repositories ? > > Certain actions may become too complex to work on mixed repositories, > however others (like Update, for instance) don't. > In any case, what it is expected here is to have the useful features that > Subversive, for instance, gives you on a working set for projects shared in > a SVN repository. And, if I remember well, the same Eclipse CVS plugin. We obtained the same even with subclipse (for SVN projects).
Pull already works for different repositories, we should at least offer that. It also already works when a working set is selected and the Git toolbar button is used.
Working on this, will push to review soon. In case all projects of a working set belong to the same repository, it shows actions for that repository. Otherwise, it shows actions that work on multiple repositories such as Pull.
Pushed for review: https://git.eclipse.org/r/30158
merged as dbedb428cc4f1fad3234b361814a8c6078ecde46
Add "Commit..." to Team context menu of working sets: https://git.eclipse.org/r/30928
(In reply to Robin Stocker from comment #20) > Add "Commit..." to Team context menu of working sets: > https://git.eclipse.org/r/30928 merged as dcb920520846d793638b96f0358a24b90bfaa771
Some more actions: Show in History, Show in Repositories View: https://git.eclipse.org/r/33025 Create Patch...: https://git.eclipse.org/r/33026
(In reply to Robin Stocker from comment #22) > Some more actions: > > Show in History, Show in Repositories View: https://git.eclipse.org/r/33025 merged as 494df40bfe4336ba71d8e4526555e4910de479ca > Create Patch...: https://git.eclipse.org/r/33026 merged as 3ab5896f037e8199334a0287ad22750221b44d7f
