Community
Participate
Working Groups
To ease discovery of the Git Staging view, the "Team" context menu should show a "Show Git Staging view" action.
Near-duplicate of bug 479676? Is there really still a need or this given that the default settings for committing is to open the staging view anyway?
This comment is from a user who's used to SourceTree and who was failing at finding a good entry-point to achieve similar results as what he can do with SourceTree. The Git Staging view matches what he would like, but he wanted to play with it *before* commit, and look for entry-points in the menu to help him and didn't find any. His first action was to go in Team > ...
New Gerrit change created: https://git.eclipse.org/r/142731
I'm also not in favor of this one. Eclipse has perspectives for a reason, and users _must_ learn that concept. There is no benefit in putting everything into the same perspective and into every menu, just to be able to provide the same "ease of discovery" in a full blown IDE, when comparing it with an SCM tool. BTW: I just compared to IDEA, and also there in the Team menu you find basically only menu items for operations (like Commit), not for opening the local changes view (since it can be opened via the View menu...). @Thomas: I'm more in favor of 479676, since that is much more context aware.
While I deeply disagree with your overall comment basically supporting making things simpler for users shouldn't be a goal and that users should be made more responsible (as history has shown it's one reason why 4+ million developers moved away from Eclipse IDE in the last ~8 years), I can get the general idea of encouraging usage of the default perspective for that task instead of "polluting" the default one. So maybe we should have a quite visible menu entry "Show in Team perspective"?
(In reply to Michael Keppler from comment #4) > @Thomas: I'm more in favor of 479676, since that is much more context aware. Yep. Show In - > Staging View, in case selection is from a Git connected project.
(In reply to Andrey Loskutov from comment #6) > (In reply to Michael Keppler from comment #4) > > @Thomas: I'm more in favor of 479676, since that is much more context aware. > > Yep. Show In - > Staging View, in case selection is from a Git connected > project. On that matter, I think that there are people who think about their goals in the "verb then target" way and who would look in a "Show In" menu, and some others that have more an "object/target then verb" (more OOP paradigm) who would more like first in "Team" to find team-related actions such as Staging View. In a context-menu, user is most probably already in the 2nd paradigm, as the entry-point for a context-menu is the selection and not the action. Both are not exclusive and many operations support both approaches and have different entry-points to map different users. EGit already support that by having the "Show In > History" and "Team > Show In history" context-menus. Both make sense. Entry-points for staging view or Team perspective should match this and be available in the various possible path users are likely to try.
we already have duplicate context menu entries in the Resource context menu: Show In > History Show In > Git Repositories and Team > Show in History Team > Show in Repositories View I vote for removing the entries under "Team" and adding the missing ones under "Show In". Compared to the context menu in the Git Repositories view the following menu entries are missing in the Resource "Show In" menu: Show In > Git Reflog Show In > Git Staging (bug 479676) I disagree with Michael about using the Team perspective. I never use it since I don't have a use case where I only look at Git views. I always use the git views in the perspective of the language tools I use for my projects (most often Java or JEE perspective).
(In reply to Matthias Sohn from comment #8) > I vote for removing the entries under "Team" Why removing entry-points that are actually used in practice? I think there are users for both context-menus, what value do we add by removing a menu that users already uses or some users will look for? I'm personally never using Show In. When I have a Team related action (like Show In History), I first go to the Team menu. > I disagree with Michael about using the Team perspective. I'm not suggesting to force its usage, I'm suggesting to 1. improve it to be more focused on the Git commit review, just like SourceTree does (that's the topic of some other bugs) and 2. if it's valuable enough, advertize it in some context-menus to let users more easily discover/use it. > I never use it since I don't have a use case where I only look at Git views. > I> always use > the git views in the perspective of the language tools I use for my projects > (most often Java or JEE perspective). Some people never use Git support of their IDE (could be Eclipse IDE or IntelliJ) and always use SourceTree or GitKraken because it does the job better for them (it's indeed much easier and pleasant to review commit in them). I think EGit has some capability to implement value for them by focusing on implementing *workflows* instead of features. My proposal to enhance and leverage the Team view fits in the idea of more easily enabling some other workflows for Git in Eclipse IDE.
