Bugzilla – Full Text Bug Listing
| Summary: | Fetch/Push dialog needs to be grossly simplified | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Remy Suen <remy.suen> |
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | b.muskalla, bhunt, deutsch, gm.romanato, Lars.Vogel, malaperle, marek.zawirski, mathias.kinzler, matthias.sohn, mn, robin, tom |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 313862 | ||
| Bug Blocks: | |||
|
Description
Remy Suen
http://egit.eclipse.org/r/715 contains some actions that could be used for this. This requires that the remote specification is completely configured in terms of URL and fetch/push spec. One would still have to select the correct destination before these actions could be executed. (In reply to comment #0) > Okay, I lied in bug 311354, I also use the command line to push. Why? Because > the dialog is confusing. As one of the main authors of fetch/push GUI, I feel being called to rise up to speak ;) Actually, I am happy with bringing idea of making this GUI easier to use! Perhaps I didn't make this GUI good enough and I always had a feeling it's too complicated, at least for newcomers. The current shape of this GUI attempts to mimic the CLI behavior in some way. However, IMHO there are couple of things which don't make it so easy to simplify this GUI, as you seem to think it is. The main problem is *how* to make it both easy to use for simple things (like pushing one selected branch), while keeping elasticity required by some users (like refspecs with wildcards). See inline comments. > ------- > > What I wanted to do: > $ git push ssh://rsuen@egit.eclipse.org:29418/egit.git HEAD:refs/for/master > > What I expected: > A wizard page with two fields, a text field for the URI and maybe a combo for > selecting the destination. You are taking very specific assumptions, even if you consider them common. You want to push one branch, being currently checked out, to some arbitrary repo, under arbitrary name. Sure, you can think it is the basic use case. Now, take a look what git gui (the one delivered together with C git) does in its push window . It takes different assumptions. The basic operation being available there is to push local branches to the remote repo, under the same branch names. You would not be able to use it for your simple use case. And another simple use case may be removing remote branch etc... What I mean is that it seems that making such "simple&flexible" GUI is non-trivial to do. I am not a very active Git user recently, so I didn't have a look at new GUIs being available, such as SmartGIT (upon the time we made push/fetch for egit, AFAIR the only sensible alternative was git gui, which I believe was also blessed by Shawn). Maybe they can inspire us with new better ideas? BTW, I don't think that selecting repository/URI on the same wizard page is a good idea. We may just skip this wizard page when selecting to push to preconfigured remote. Maybe somebody already implemented that, I've seen Repositories View patches flying around, but I am not following in details. > Extras can come in later wizard pages but I should > be able to "early finish" the wizard. IMO wizard pages is not a good tool here for separating between these simple use cases and complex ones. Maybe some hidden part of a page? > Multiple input fields with completion support, many choices for adding a spec, > one of which is a button that says "Add spec" but with an 'X' marker (upon > careful inspection you realize it is something to do with _deletion_), > checkboxes under a 'Force Update' column and a trash can icon. The thing is, that git CLI actually gives us a way to express all these complex options. What we have tried to do is to allow doing at least the same things. For example pushing basing on a remote configuration refspecs, used by C Git. I believe that user familiar with git push and refspecs syntax understands how this GUI works, although I can imagine that usability can be improved :) I don't have time for dev. egit now and I maybe I am not good at this GUI works. The fail part is, that I haven't came up with a good idea how to mix that elasticity with simple use cases. Perhaps... having two navigable lists of "local" and "remote" branches (instead of complex combos), would simplify the things, allowing user to create some basic refspecs quickly. Or maybe somebody has better idea? > The most > exciting thing is probably that the 'Next >' button is enabled, implying more > options for you to pick in page two. > http://wiki.eclipse.org/images/9/9c/Egit-0.6-007-PushRefSpecifications.png Because there is a confirmation page and you can come back? Perhaps these buttons could be easily renamed: finish->push vs next->try or whatever. > > ------- > > I do use the dialog to fetch because it seems to have magically guessed what I > wanted to fetch. I have since never touched the input of that dialog for > fearing of screwing it up. If your main use case for egit repo is pushing HEAD as refs/for/master, you can actually consider saving that magic as a remote configuration. So you can always directly push that stuff to gerrit (I can imagine being it as easy as menu selection Team->Push To->gerrit/origin->Done). > I've spoken to two other people on IRC that also > agree that this dialog is way too cluttered. I imagine there are more people > out there that feel the same. That's bad news, and could be a reason to change something. On the other hand, are they familiar with CLI git push options? > My question to you is, do you fetch/push using EGit? I am not using EGit very often recently. > And if yes, how often do > you actually change the input fields of this dialog? I am not really sure is it the correct question. Don't forget about more sophisticated setups (perhaps as a extended part of a wizard page?). Not chanigng input fields -> save it as a remote configuration. (In reply to comment #2) > The current shape of this GUI attempts > to mimic the CLI behavior in some way. That seems to be the case for most things in EGit in my opinion. > The main problem is *how* to > make it both easy to use for simple things (like pushing one selected branch), > while keeping elasticity required by some users (like refspecs with wildcards). That's what this bug is for, to figure out how to make it easier. :) > We may just skip this wizard page when selecting to push to > preconfigured remote. This sounds fine to me. > IMO wizard pages is not a good tool here for separating between these simple > use cases and complex ones. Maybe some hidden part of a page? We should make sure the dialog does not grow too big vertically though. > I > believe that user familiar with git push and refspecs syntax understands how > this GUI works I would imagine. Based on my googling, they did seem to be options that you could pass on the command line. > > The most > > exciting thing is probably that the 'Next >' button is enabled, implying more > > options for you to pick in page two. > > http://wiki.eclipse.org/images/9/9c/Egit-0.6-007-PushRefSpecifications.png > > Because there is a confirmation page and you can come back? Guilty as charged. :) To be honest I didn't even look at the next page in detail. I saw another table, raised my hand and decided to just close the dialog. > Perhaps these buttons could be easily renamed: finish->push vs next->try or > whatever. I don't think this is a good idea but would be interested in what others have to say. > On the other hand, are they familiar with CLI git push options? I spoke to one of them for quite a while about this but yes, he seemed like he fully knew what the dialog was doing, or at least, what options the dialog was offering to the user. Anyway, user interface design is a touchy issue because everyone has their own way of using a tool. Since no one else has filed a bug on this matter, I guess people are either comfortable with the dialog or are just using the command line. So this may not be as big of a deal as I make it out to be. It's great to provide a full-function interface, but in this case it would be more helpful to provide a *simple* interface, and use the command line for more complicated operations. I find it confusing... I think the interface is harder to use and understand than using the command line, which defeats the purpose. In regard to "do you fetch/push," I totally gave up trying to get PUSH to do anything comprehensible and I go to the command line. (In reply to comment #4) > It's great to provide a full-function interface, but in this case it would be > more helpful to provide a *simple* interface, and use the command line for more > complicated operations. I find it confusing... I think the interface is harder > to use and understand than using the command line, which defeats the purpose. > > In regard to "do you fetch/push," I totally gave up trying to get PUSH to do > anything comprehensible and I go to the command line. The solution may be then to give user a choice in the wizard - simple or advanced interface. In that case the alternative simple interface might be developed. However, I strongly disagree that for more advanced uses we should fall back to CLI. Isn't the long-term goal to be able to have fully functional Git support within Eclipse, independent from CLI, and without need for falling back to CLI from time to time? > In regard to "do you fetch/push," I totally gave up trying to get PUSH to do
> anything comprehensible and I go to the command line.
i am currently migrating from svn to git and face the same question: do i continue trying to get this dialog to work or tell the others to switch to the command line for pushing purposes?
In the user guide we describe the two ways to push which are currently available [1]. - For the simple direct push you first configure a push URL defining what to push from where to where once and from then on you may simply run push without any wizardry [2]. This is similar to configuring a remote url and push specification from git CLI [3]. This is what I am using in 99% of all cases. - The other way is the full blown push wizard [3] which is a bit heavy weight I have to admit. [1] http://wiki.eclipse.org/EGit/User_Guide#Pushing_to_other_Repositories [2] http://wiki.eclipse.org/EGit/User_Guide#Direct_Fetch_and_Push_Support [3] http://wiki.eclipse.org/EGit/Contributor_Guide#Adding_a_remote [4] http://wiki.eclipse.org/EGit/User_Guide#Push_Wizard I am not sure if you have read this documentation ? Does it help ? (In reply to comment #7) > In the user guide we describe the two ways to push which are currently > available [1]. I've not tried the new way but I think (part of) the problem here is that we are all used to 'Team > Commit...' in CVS/SVN. Thus, we are all inclined to just push using the same 'Team' menu. I am not sure how many people would even realize that you can fetch/push from the 'Git Repositories' view. (In reply to comment #7) > In the user guide we describe the two ways to push which are currently > available [1]. > > - For the simple direct push you first configure a push URL defining what to > push from where to where once and from then on you may simply run push without > any wizardry [2]. This is similar to configuring a remote url and push > specification from git CLI [3]. This is what I am using in 99% of all cases. > > - The other way is the full blown push wizard [3] which is a bit heavy weight I > have to admit. > > [1] http://wiki.eclipse.org/EGit/User_Guide#Pushing_to_other_Repositories > [2] http://wiki.eclipse.org/EGit/User_Guide#Direct_Fetch_and_Push_Support > [3] http://wiki.eclipse.org/EGit/Contributor_Guide#Adding_a_remote > [4] http://wiki.eclipse.org/EGit/User_Guide#Push_Wizard > > I am not sure if you have read this documentation ? Does it help ? OK, now I see my confusion. I was able to make this work after re-reading: http://wiki.eclipse.org/EGit/User_Guide#Direct_Fetch_and_Push_Support The problem is that after configuring the project to Pull, it was *totally* not clear that I needed to separately configure for Push. (When I do all this from the command line, I can just type "git push" and it works, so I expected eGit to do the same thing.) Now that I have set up the Push spec as described here: http://wiki.eclipse.org/EGit/User_Guide#Direct_Fetch_and_Push_Support ... now Push works completely like I had expected. It was not hard to do, but I had no idea it was necessary after setting up Pull. Seems like new eGit users would have less trouble with Push if either: 1) The push spec was (optionally?) created along with the Pull spec. Would it be reasonable/dangerous/inadvisable to create the default push spec when the pull spec is created? (To get this to work for me, I just copied the Pull spec to create the Push spec.) or... 2) The error message when trying to Push with no spec defined would indicate the problem more clearly. If the error message explicitly indicated that the Push spec was missing, I'd have figured this out long ago. (WooHoo! now this works great!) I see I didn't describe this as well as I could have... it was not exactly the doc link I referenced that solved my problem. But when I went to those dialogs is when I realized that Push had not been set up at all. I think the main thing the CLI does better is that it uses sensible defaults and hides the advanced options from the unsuspecting user. I am currently facing the challenge of getting developers who have grown up in a world of CVS and SVN to give git a chance. And the rather complicated push and fetch wizards - which I, after using git for a while and getting along with the CLI quite well, had trouble figuring out - did not really help :(
I agree with Tom that it is not clear that a push needs to be configured separately. Also, I'd expect clone to configure all that for me automagically, just as the CLI clone does (currently eGit only seems to configure a fetch location).
I also agree with Remy that we're all used to having everything available in the Team context menu.
I assume that for a majority of people the standard workflow is to have one main remote repository to push to and fetch from, and usually the local repository is a clone of that, so remote branches mostly correspond 1:1 to local ones. So far, this assumption seems to hold based on my discussions with a couple of other people, git's own default setup and most workflows encountered in blog posts, tutorials and religious documents on git found on the net.
Therefore, I would suggest a couple of things:
1. Configure default push/fetch on clone
This is how the majority of users will get to their repositories and should be set up with everything to work with minimal additional work required. Also, git clone does this as well...
2. Support adding a matching push configuration when creating a fetch configuration, as Tom suggested
3. Replace the "Push..." and "Fetch..." menu entries with "Push" and "Fetch" and "Push to ..." and "Fetch from ..." where:
3.1 "Push" and "Fetch" use the default configuration (i.e. push/fetch config of the default remote) without opening the wizard (and without having to go to $repo->Remotes->origin->that config)
3.2 Push to... and Fetch from ... open the wizard like they do now
This way, the most frequent workflow I'd expect to encounter in the wild world works a lot less obstrusively and still no flexibility is lost. ("Push" and "Fetch" should most likely be deactivated if no default config is available, though). Together with 1. pushing and fetching should work for most people without having to do any additional configuration this way. The actions in 3.1 should most likely pop up a confirmation dialog, maybe with an additional "Run in wizard" button to get to the wizard.
4. Add a flag to the wizard to add the current remote location and/or push/fetch configuration to the repository
It's just more convenient and easier to remember to have the readily available context action for the wizard as a starting point if I want to push/fetch something different.
*** Bug 332263 has been marked as a duplicate of this bug. *** Hello, I agree that the push dialog is not that user friendly, and I find especially dangerous the "force update" check box: a colleague of mine made a push with "force update" selected, thus breaking the history of the primary repository. I surely understand that the only person who has to be hold responsible for the damage is my colleague who did not know/understand the implications of the "force update" check box (probably being fooled by the fact that we just recently moved to GIT, coming from another old and proprietary VCS whose client offered a "force" checkbox which had a completely different meaning), nevertheless I kindly ask you to evaluate alternative ways to enable a user to perform a "force udpate". After all, I believe one should need to "force update" only in very rare occasions and as such that option may be a better fit for a later page in the wizard that the user may not be required to view if the finish button was already enabled and the option should default to false. As a side note, let me add that after cloning a repo with EGit 1.0, the first time you perform a fetch operation the fetch dialog spots "Force Update" pre-checked. A new and unexperienced user may save the dialog configuration "as is" and use it for every future "Fetch from upstream" operations, thus inheriting the "Force Update" behavior for all his/her future fetch operations. (In reply to comment #13) > Hello, I agree that the push dialog is not that user friendly, and I find > especially dangerous the "force update" check box: a colleague of mine made a > push with "force update" selected, thus breaking the history of the primary > repository. > > I surely understand that the only person who has to be hold responsible for the > damage is my colleague who did not know/understand the implications of the > "force update" check box (probably being fooled by the fact that we just > recently moved to GIT, coming from another old and proprietary VCS whose client > offered a "force" checkbox which had a completely different meaning), > nevertheless I kindly ask you to evaluate alternative ways to enable a user to > perform a "force udpate". After all, I believe one should need to "force > update" only in very rare occasions and as such that option may be a better fit > for a later page in the wizard that the user may not be required to view if the > finish button was already enabled and the option should default to false. You may consider to install a hook preventing forced updates on the git server you are pushing to (e.g. see http://book.git-scm.com/5_git_hooks.html and look for "GIT_DIR/hooks/update"). > As a side note, let me add that after cloning a repo with EGit 1.0, the first > time you perform a fetch operation the fetch dialog spots "Force Update" > pre-checked. A new and unexperienced user may save the dialog configuration "as > is" and use it for every future "Fetch from upstream" operations, thus > inheriting the "Force Update" behavior for all his/her future fetch operations. this looks like a bad default, I think we should change that [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. This is better nowadays: * We have dedicated wizard for pushing to Gerrit * Push to Upstream works nicely * Many bug fixes in this area Some more improvements: * Wizard dedicated for pushing a branch, see bug 382190 (implemented, in review) * Wizard for pushing tags, see bug 341076 * Wizard for deleting branches and tags on the remote, see bug 418193 Closing this as fixed, please see other bugs or report new ones for use cases that are not yet covered. *** Bug 313862 has been marked as a duplicate of this bug. *** |
