Bugzilla – Full Text Bug Listing
| Summary: | Allow commit and push to remote in one interaction | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Miles Parker <milesparker> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | adietish, benjamin.dev, bruno.do.medeiros, caniszczyk, daniel_megert, info, kevinsheedy, Lars.Vogel, manderse, markus.kell.r, matthias.sohn, remy.suen, richard.eckart, robin, rsternberg, stryker |
| Version: | 2.0 | ||
| Target Milestone: | 2.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 388913, 389708 | ||
| Attachments: | |||
|
Description
Miles Parker
(In reply to comment #0) > It would be nice to have a one step "commit and push" action. This might use > the default push setup so that you could simply click the commit and push > button and have the push happen as well if you have the remote push set up > correctly. Alternatively you might combine the two into a single wizard. As I become more familiar with Git and EGit, probably a better approach would be to add a check box in the commit dialog for "also push to remote repos". +1 I think whether you want to push now or later is not a personal preference but depends on the task (e.g. a multi-step change) and maybe on the network availability. I presume that I would often forget to check the status of the checkbox and thus forget to push or push unintentionally. What about a dialog that pops up after committing: Push changes to upstream [Ok] [Later] ? Popups a always getting annoying. I think a optional flag would be better. Agree, unnecessary pop-ups are annoying. Anyway, I don't think that a check box is suitable for a decision that might change from commit to commit. We currently need this functionality for JBoss Tools (https://issues.jboss.org/browse/JBIDE-9511) and we would gladly contribute a patch for this. (In reply to comment #6) > We currently need this functionality for JBoss Tools > (https://issues.jboss.org/browse/JBIDE-9511) and we would gladly contribute a > patch for this. +1 find the contributor guide here [1] let me know if you need any help [1] http://wiki.eclipse.org/EGit/Contributor_Guide (In reply to comment #5) > Agree, unnecessary pop-ups are annoying. Anyway, I don't think that a check box > is suitable for a decision that might change from commit to commit. That's an important point. You'd really want to avoid the case where someone pushed when they didn't intend to just because they'd forgotten to uncheck the dialog. What I'm thinking is that the box should always be unchecked when the dialog loads regardless of what the user did on the last push. Does this address your concern? It would mean that the workflow is unchanged for those users who aren't interested in this feature but would avoid more popup thrash. Yes, that sounds reasonable to me. That would be similar to the "delete from disk" checkbox that you get on Project -> Delete. It also seems to be off by default regardless of the last delete operation. Created attachment 202005 [details]
allow the user to push the changes when committing
I added a checkbox to the commit dialog and execute the push command if it is checked.
(In reply to comment #10) > Created attachment 202005 [details] > allow the user to push the changes when committing > > I added a checkbox to the commit dialog and execute the push command if it is > checked. Could you push this patch to Gerrit for review as described in the contributor guide [1] ? I can assist if you face problems with that. [1] http://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches I currently push to gerrit and the discussions are going on in the review of http://egit.eclipse.org/r/#change,4103,patchset=2: The issue came up what kind of push shall be executed: the fully fledged push with UI that would allow you to choose the repo to push to or the simple one that just pushes to upstream. Matthias argues that the majority of users would only want to push to upstream. We have the requirement to be able to push to a repo that is not the origin (we work on tooling that would push a githup project to a cloud server). What about providing 2 checkboxes? 1 to push to upstream and anotherone that would allow you to choose the repo to push to? Another issue that came up with the review of my latest patch in gerrit (http://egit.eclipse.org/r/#change,4103,patchset=2) is that the PushActionHandler is not active if you choose "Commit" in the context menu while selected a file/package/folder (and not the project). The push of course then cannot be executed since the PushActionHandler is bound to the following enablement expression: <adapt type="org.eclipse.core.resources.IProject"> </adapt> I could solve that easily by changing the expression to enable the handler whenever a IResource is selected (or add an adapter factory that would adapt a IResource to an IProject). I fear though - and I'm not used enough to use egit so far - that this change may enable the push command in cases that you dont want it to be available in the context menu. I assume you had reasons to not enable the PushActionHandler when files/packages/folders were selected. Any suggestions? (In reply to comment #13) For what it is worth the fact I have to navigate up to the root of the project to perform Push is one of my biggest annoyance at the moment with egit - I wish it was reachable from any resource. (In reply to comment #14) > For what it is worth the fact I have to navigate up to the root of the project > to perform Push is one of my biggest annoyance at the moment with egit - I wish > it was reachable from any resource. Same for me. (In reply to comment #15) > (In reply to comment #14) > > For what it is worth the fact I have to navigate up to the root of the project > > to perform Push is one of my biggest annoyance at the moment with egit - I wish > > it was reachable from any resource. > > Same for me. Hey, get your own bug! ;) (In reply to comment #16) > Hey, get your own bug! ;) Sorry, Miles. Actually, we already have bug 302078. :P (In reply to comment #17) > (In reply to comment #16) > > Hey, get your own bug! ;) > > Sorry, Miles. Actually, we already have bug 302078. :P oh, awesome, good to know. I'll comment the bug there and ask for special reasons to have push only enabled on projects? If not it would pretty much meet my needs in the usecase of this bug (I need the push handler to be activated when you commit). Created attachment 203688 [details]
shows a possible layout for push options in the commit dialog
I added a screenshot that shows how the commit-dialog could look like if it would allow you to push your changes when the commit was successful.
It allows you to choose not push, to push to upstream or to push to a specific remote (you'll select in the upcoming dialog).
The default is not to push anything (left most radio is selected)
(In reply to comment #19) > Created attachment 203688 [details] > shows a possible layout for push options in the commit dialog $.02: It seems that we could simplify that. Maybe just a single checkbox with default off. Might not even need a separate sash. Presumably if someone wanted to push somewhere that wasn't the default repos they should probably be configuring that repos somewhere else. I see this as more of a quick convenience thing. (In reply to comment #20) > $.02: It seems that we could simplify that. Maybe just a single checkbox with > default off. Might not even need a separate sash. Presumably if someone wanted > to push somewhere that wasn't the default repos they should probably be > configuring that repos somewhere else. I see this as more of a quick > convenience thing. +1 That was also my thinking when I saw the draft. The radio buttons make it more complicated to use because choosing between three options demands more brain cycles than answering a yes/no question. Users will have to read the texts to make the decision, maybe even wonder "but my upstream repository *is* a remote repository". A single checkbox named "push to upstream" is much easier to grasp. If it's checked, the commit will be pushed. You don's have to read. Simple things (push to upstream) should be simple, advanced things (push to another repo) should be possible - and they are already. I guess most of the users will have only one remote repository. +1 For A single checkbox named "push to upstream" ok, to switch to a single checkbox which would allow you to push to upstream and dropping the capability to push to a specific remote. Pushing to a specific remote would only be available in an additional step, choosing "Push" in the context menu. On the other hand I still believe that a separate section is a good thing to have since it clearly separates this from the rest visually. To me it is beneficial to get it visually already that this is another option (not related to the sections above) Created attachment 203744 [details]
shows a possible layout for push options in the commit dialog (2)
added a new screenshot of a possible layout in the commit dialog. It now uses a single checkbox that would allow you to push changes to upstream. The checkbox is in its own section so that this possibility is visually separated from the rest.
(In reply to comment #24) > Created attachment 203744 [details] > shows a possible layout for push options in the commit dialog (2) > > added a new screenshot of a possible layout in the commit dialog. It now uses a > single checkbox that would allow you to push changes to upstream. The checkbox > is in its own section so that this possibility is visually separated from the > rest. +1 I think it does make sense to have it visually separated. For generality, you might call the heading "Options" or even "Post-Commit Actions" or something like that. (In reply to comment #16) > Hey, get your own bug! ;) Just curious, but how do we push along bugs that don't seem to move anywhere? I've had a bug opened WITH a patch for more than 2 months and nobody has addressed it. https://bugs.eclipse.org/bugs/show_bug.cgi?id=353170 I would love to know what the process is to make sure this stuff gets seen. Kinda sad that a bug with a patch on it gets ignored for so long. (In reply to comment #26) > Just curious, but how do we push along bugs that don't seem to move anywhere? EGit is no different from any other open source project so I would just do the usual thing. Ping the bug, ask on the mailing list, blog about it and draw other's attention to it so more people are commenting/CC'ing themselves on the bug, vote on the bug, etc, etc. Of course, at the end of the day, this is open source and I can't force someone else to do anything. > I've had a bug opened WITH a patch for more than 2 months and nobody has > addressed it. I think you may get more mileage if you pushed your change set to Gerrit for review. I'd like to suggest that "Commit and Push" become a top level command with it's own keybinding. This could raise the commit dialog with the Push checkbox pre-selected. This would make the commit and push truly a one step operation. I think this is really important in order to get the SVN/CVS users on board the Git bandwagon. If I'm making 50 commits a day, I really won't want to manually click a checkbox every time. *** Bug 365406 has been marked as a duplicate of this bug. *** +1 for "commit and push". IntelliJ has such a button in the GIT commit dialog, and I like it very much. I pushed a change to gerrit, that implements a checkbox (as shown in the screenshot) that would allow users to push to upstream when checked. https://git.eclipse.org/r/7487 Instead of a global keybinding (which are crowded already anyhow) I'd suggest to store the checked state of the "Push changes to Upstream"-checkbox in the Eclipse preferences. This would allow you to set it once and have it checked in every upcoming commit. merged as f1550b8293315b84b476a65953555102f7e8c6d5 Verified in 2.1.0.201209051725. Nice! (In reply to comment #21) > I guess most of the > users will have only one remote repository. I'm not sure that this is a valid assumption for Gerrit users. I would think having a separate remote for Gerrit is a common configuration, and having the option to push directly there when committing would be quite useful. As it stands, I have to right click > team > remote > push to Gerrit, and that only brings up a push dialog. Having a "Push to Gerrit" checkbox in the commit dialog which pushes in one step would be a lot simpler. I saw this today in my regular old Eclipse for the first time. It's been an epic -- thanks to everyone who contributed, commented, tested, verified, etc.. :) The funny thing is, now that I have it, I've kind of gotten used to the git way. ;P Actually I'm finding this quite dangerous, because I forget that the box is checked. I think it would be better just to have a separate button to commit and push, instead of a check box. (In reply to comment #37) > Actually I'm finding this quite dangerous, because I forget that the box is > checked. I think it would be better just to have a separate button to commit > and push, instead of a check box. After working with this for a while I tend to agree. It turned out that in the end I had to deselect that checkbox again. To sum up there are apparently 2 distinct usage patterns: * people that have several commits a day and want to always push / or not to push upstream. They dont want to manually ensure the push's done on every commit (therefore the state of the checkbox is currently stored to the preferences currently) * people that have several different commits a day that may or may not be pushed upstream. They tend to forget about the checkbox and end up pushing where they didn't want to and vice versa. To me it looks like having a 2nd button fullfills these 2 requirements the best. The default button would still do a simple commit whereas a new button "commit and push" would do the push, too. Any thoughts? Alternatives? I'd open a new bugzilla for this change then. +1 for the 2 buttons approach ("Commit and Push", "Commit"). "Commit and Push" would also be useful as a separate command in the Git Staging view toolbar.
Sam and I were talking about this a bit more yesterday. As Andre suggests, there are some workflows that work very well with current design and there are some that work not well at all. The worst case I can think of is the "doh! I forgot to pull before pushing and now I've tried to commit a fast-forward change that's been kicked back". Then you have to do the whole dance of trying to preserve your changes reset and then commit again without borking the remote repos. Almost all of these workflows are repository specific. If you're like me you might have some repos which are "mine" that I just want to commit and push to. There are some like Gerrit that I may want to push to immediately, but may want to batch, there are some I never want to push automatically to, and there are some like the master dev branches that I want to be sure to always pull from before pushing. Probably the two button approach does handle all of those cases best, but OTOH it might be nice to be spared the extra cycles of having to think through that every time. So... what about storing the preference in git config? You could do that at the repos level and/or at the global level. It might be too confusing/dangerous though because the preference default state wouldn't always be obvious. You'd have to surface that in the commit UI somehow and it would be a design challenge to do that in a way that didn't add to the confusion. I sill think the 2 button approach without any stored preference is best, but as Miles pointed out this functionality is less useful if the remote is a git repository that many other people are pushing to, as you normally have to pull first anyway. Would it make sense to have the button do commit, pull, and push? (In reply to comment #42) > I sill think the 2 button approach without any stored preference is best, I complete agree. IMHO the 2 buttons approach is the best one so far. > but as Miles pointed out this functionality is less useful if the remote is > a git repository that many other people are pushing to, as you normally have > to pull first anyway. Would it make sense to have the button do commit, > pull, and push? Looks like an interesting approach. To get you right: You suggest a first button to just commit. Another one that would commit, pull and push? The push would then get skipped if the pull had merge errors, right? (In reply to comment #42) > I sill think the 2 button approach without any stored preference is best, Me too. > but as Miles pointed out this functionality is less useful if the remote is > a git repository that many other people are pushing to, as you normally have > to pull first anyway. Would it make sense to have the button do commit, > pull, and push? I would not want too much logic here. Simple 'Commit' and 'Commit & Push' would be enough for me. I've filed bug 389708 for that. We can continue the discussion there. (In reply to comment #44) > (In reply to comment #42) > > but as Miles pointed out this functionality is less useful if the remote is > > a git repository that many other people are pushing to, as you normally have > > to pull first anyway. Would it make sense to have the button do commit, > > pull, and push? > > I would not want too much logic here. Simple 'Commit' and 'Commit & Push' > would be enough for me. Agreed. Doing a pull in between could have many potential problems. E.g. it is possible to have a conflict-free pull resulting in non-compiling code, in which case that would be pushed. (In reply to comment #45) > (In reply to comment #44) > > (In reply to comment #42) > > > but as Miles pointed out this functionality is less useful if the remote is > > > a git repository that many other people are pushing to, as you normally have > > > to pull first anyway. Would it make sense to have the button do commit, > > > pull, and push? > > > > I would not want too much logic here. Simple 'Commit' and 'Commit & Push' > > would be enough for me. > > Agreed. Doing a pull in between could have many potential problems. E.g. it is > possible to have a conflict-free pull resulting in non-compiling code, in which > case that would be pushed. That's a good point. There's a problem with Git's model in that even if you pull first and then push, there's a good chance somebody else will have pushed in between, in which case you have to pull again. But I guess that can't be solved purely in the UI. (In reply to comment #45) > (In reply to comment #44) > > (In reply to comment #42) > > > but as Miles pointed out this functionality is less useful if the remote is > > > a git repository that many other people are pushing to, as you normally have > > > to pull first anyway. Would it make sense to have the button do commit, > > > pull, and push? > > > > I would not want too much logic here. Simple 'Commit' and 'Commit & Push' > > would be enough for me. > > Agreed. Doing a pull in between could have many potential problems. E.g. it is > possible to have a conflict-free pull resulting in non-compiling code, in which > case that would be pushed. Actually, the same thing can happen when Gerrit automatically rebases a patch set before pushing it, but the automatic rebase is still a very useful feature. So I still think this could be worth having. *** Bug 389593 has been marked as a duplicate of this bug. *** |