Community
Participate
Working Groups
Build Identifier: The commit menu item is available on all file sand directories, however fetch, pull, push, etc. are only available at the top level. It would be nice if these menu items were available everywhere. Reproducible: Always
Since 0.11, we can configure the Git Action Set with a "Push changes to Upstream" button. This button is available on any Git-controlled resource. I think that this is much more usable than right-clicking Team->Push etc., so I wonder if we still need this feature.
+1 for Team -> Push always available. We are used to do team related work there.
(In reply to comment #2) > +1 for Team -> Push always available. We are used to do team related work > there. So there was no special reason to enable push when projects are selected only? It would greatly meet my needs to have push enabled even on files and folders in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=330048
(In reply to comment #3) > (In reply to comment #2) > > +1 for Team -> Push always available. We are used to do team related work > > there. > So there was no special reason to enable push when projects are selected only? > It would greatly meet my needs to have push enabled even on files and folders > in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=330048 Well, technically there is no reason to enable push on files, but it might badly interact with the mindset of people coming from other team providers in that they might think they can push a file or folder individually somewhere. Having the action on projects only isn't really the solution, but at least it reminds you that you can't push a single file... From that point of view, one could argue that push should only be available on the Repositories View (as it has nothing or at least only little to do with the resources shown in the project explorer), but then of course we need to appear somewhere in the Team menu... Having said that, I see no technical problem, but rather a user interaction problem. Another consideration should be that the Team menu is already very big and complex, and we should be careful not to overload it further.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > +1 for Team -> Push always available. We are used to do team related work > > > there. > > So there was no special reason to enable push when projects are selected only? > > It would greatly meet my needs to have push enabled even on files and folders > > in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=330048 > > Well, technically there is no reason to enable push on files, but it might > badly interact with the mindset of people coming from other team providers in > that they might think they can push a file or folder individually somewhere. Since I can do git push anywhere on the command line this really shouldn't be a problem IMO. Just make the dialog show explicitly that it is pushing git repo for XYZ project to whatever remote destination(s).
(In reply to comment #4) > Having the action on projects only isn't really the solution, but at least it > reminds you that you can't push a single file... From that point of view, one > could argue that push should only be available on the Repositories View (as it > has nothing or at least only little to do with the resources shown in the > project explorer), but then of course we need to appear somewhere in the Team > menu... > Having said that, I see no technical problem, but rather a user interaction > problem. Another consideration should be that the Team menu is already very big > and complex, and we should be careful not to overload it further. I think Mathias makes important points. The Eclipse interface is so polluted with menu items and we have a real tendency to put things on the context-menu that aren't really object specific at all. I'm dealing with that issue on another project right now. In this case it's arguably not as huge a deal as they are in the Team menu but this has always been confusing for me for precisely the reason that push didn't seem to have anything to do with a specific project. Because it doesn't. :) On the other-hand, where do you put the damn thing? This is not such an incidental issue when as a git newbie, you click "Reset.." on your project, choose Hard, sort of don't pay attention to the dialog that comes up next, and find your entire repos replaced. Ask me how I know..
Then lets talk about what should be removed from the menu so Commit/Push/Pull becomes available - the three most used commands is it not ?
(In reply to comment #7) > Then lets talk about what should be removed from the menu so Commit/Push/Pull > becomes available - the three most used commands is it not ? As said above, the most used commands (up to eight) can be configured to appear in the main toolbar and/or main menu by configuring your perspective to show the Git Command Group. This is what I use almost exclusively and I find it much easier to work with than the Team context menu. Admittedly, this feature is a bit obscure, but we as Git just can't assume that we should always appear there and have to leave the task of doing this configuration to the end user.
(In reply to comment #8) > (In reply to comment #7) > > Then lets talk about what should be removed from the menu so Commit/Push/Pull > > becomes available - the three most used commands is it not ? > > As said above, the most used commands (up to eight) can be configured to appear > in the main toolbar and/or main menu by configuring your perspective to show > the Git Command Group. This is what I use almost exclusively and I find it much > easier to work with than the Team context menu. Admittedly, this feature is a > bit obscure, but we as Git just can't assume that we should always appear there > and have to leave the task of doing this configuration to the end user. Are you sure? I think this is a common enough usage that it might be nice to have it included at least for the most common perspectives such as java. I don't think anyone is going to install git without the idea that they would want access to these, and I certainly wasn't aware of them. Also when Git makes it into Juno SDK build :) this would be the default Eclipse workspace setup.
(In reply to comment #9) > Are you sure? I think this is a common enough usage that it might be nice to > have it included at least for the most common perspectives such as java. I > don't think anyone is going to install git without the idea that they would > want access to these, and I certainly wasn't aware of them. Also when Git makes > it into Juno SDK build :) this would be the default Eclipse workspace setup. It's a matter of being a good citizen in an extensible SDK. Git is just one version control system among others and forcing it into the main menu implies that it is somehow more "right" than another one (imagine all VCS adding stuff to the main menu)... In other words: we can't assume that we are going to be used just because we are installed.
IMHO we're getting of track if we start talking about the main menu and the toolbar. To me verybody is used to look for the team options in the context menu and that's exactly where "push to" is missing if you select a file/folder. To me putting it into the main-menu or the toolbar is not an equivalent alternative. Furhtermore having a default set 'right' is something very important to get adopters served in an intuitive manner. It's even more true since commit/push/pull are the most frequent commands. "Push to" is to me even more important than "Advanced" which is already available in the context menu for files/folders.
Bug 330048 has been fixed, we now have "Commit and Push" in both the commit dialog and the staging view. Currently, repository-wide actions are only available from the project context menu, while the context menu of files and folders is nice and small as it only contains file-level actions. Also see comment 4, +1 to that. Maybe adding a "Repository" submenu to the file/folder menu would be an option? This way, there would only be 1 additional menu entry and maybe it would also make it clearer to the user that the actions within that submenu are executed on the repository, not the selected file.
Adding the "Remote" or a "Repository" menu option seems reasonable. I've started using EGit more lately and I haven't been missing this feature as much as I used to. I've found that keeping the "Git Staging" and "Git Repositories" views open all of the time really helps. I agree with the thought from comment#4 that some users would get confused about what exactly is being pushed.
(In reply to Jon Schewe from comment #13) > I've started using EGit more lately and I haven't been missing this feature > as much as I used to. I've found that keeping the "Git Staging" and "Git > Repositories" views open all of the time really helps. (Off topic:) Yes, any idea how we could make the "Git Staging" view more visible? It's so comfortable to use, but I think that currently many people don't even know about it. Maybe we could propose to open it the first time a user does Team > Commit... ? > I agree with the thought from comment#4 that some users would get confused > about what exactly is being pushed. Do you think that's the case even when the menu would be called Team > Repository > Push to Upstream?
(In reply to Robin Stocker from comment #14) > (In reply to Jon Schewe from comment #13) > > I've started using EGit more lately and I haven't been missing this feature > > as much as I used to. I've found that keeping the "Git Staging" and "Git > > Repositories" views open all of the time really helps. > > (Off topic:) Yes, any idea how we could make the "Git Staging" view more > visible? It's so comfortable to use, but I think that currently many people > don't even know about it. > > Maybe we could propose to open it the first time a user does Team > > Commit... ? I don't know, but that might work. It is quite handy. > > > I agree with the thought from comment#4 that some users would get confused > > about what exactly is being pushed. > > Do you think that's the case even when the menu would be called Team > > Repository > Push to Upstream? That would probably be OK.
(In reply to Robin Stocker from comment #14) > (In reply to Jon Schewe from comment #13) > > I've started using EGit more lately and I haven't been missing this feature > > as much as I used to. I've found that keeping the "Git Staging" and "Git > > Repositories" views open all of the time really helps. > > (Off topic:) Yes, any idea how we could make the "Git Staging" view more > visible? It's so comfortable to use, but I think that currently many people > don't even know about it. > > Maybe we could propose to open it the first time a user does Team > > Commit... ? or simply open the staging view when the user clicks "Team > Commit..." and delete the commit dialog ;-?
(In reply to Matthias Sohn from comment #16) > or simply open the staging view when the user clicks "Team > Commit..." and > delete the commit dialog ;-? +1 from me, but probably -1 from others ;).
Proposed change to implement this: https://git.eclipse.org/r/33028
(In reply to Robin Stocker from comment #18) > Proposed change to implement this: https://git.eclipse.org/r/33028 merged as 265e5a1cf7530a3a8a46a7d0958d03b02b565bd6
