Home » Eclipse Projects » EGit / JGit » Make egit 'Checkout' match egit 'Switch to'(egit Checkout should behave the same as egit Switch To)
Make egit 'Checkout' match egit 'Switch to' [message #692972] |
Tue, 05 July 2011 15:09 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
The difference between the egit commands Checkout and Switch To seems overly subtle at best and confusing at worst. I think they should be made the same.
The "Checkout" command lets you switch to another branch, tag or reference; that's it.
The "Switch to" command has options to create a new branch and switch to it, switch to an existing branch (these are listed in in the submenu), or "Other", which brings up the Checkout dialog.
The "Checkout" command is in the Git toolbar and is also available on the Git menu, where it's confusingly called "Switch to...". The _other_ "Switch To" is on the Team menu.
I suggest that these two be merged into a single egit command that will allow you to create and switch to a new branch, or switch to an existing branch, tag or reference. Users can invoke it from the Git toolbar, the Git menu or the Team menu, as they prefer.
This will be simpler for new egit users, and will also encourage the use of feature branches, a key bit of git learning for developers coming from svn.
|
|
| | | | | |
Re: Make egit 'Checkout' match egit 'Switch to' [message #731022 is a reply to message #731011] |
Thu, 29 September 2011 17:48 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Robin Rosenberg wrote on Thu, 29 September 2011 19:02The direction is to use the same terminology as other team providers.
I think the question deserves a second thought: what will cause least surprise and fewer frustrated users? Obviously there's reasons to align EGit terminology with git terminology. OTOH, if EGit does its job well, EGit users don't need to see git, for them EGit is the tool. So the first contact with EGit makes a big difference to users.
And then, if you need to drop down to command line, I think that's a step where some translating is quite normal. So maybe the documentation I suggested should just be that: documenting the mapping from EGit UI actions to git CLI actions.
Concluding, after second thought, yes, I think uniformity among team provider plug-ins in Eclipse is the higher goal, here. It's not perfect but we do live in Babel already, don't we?
Quote:en_US for Eclipse terminology
en_US_Git for Git terminology
I love it
Stephan
|
|
|
Re: Make egit 'Checkout' match egit 'Switch to' [message #731267 is a reply to message #731022] |
Fri, 30 September 2011 13:06 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
You can thank Linus for this particular Babel I think he went out of his way to use VCS terms differently...
More seriously, the frustration of new users is inherent in Git. Users have to be willing to spend quite a bit of time understanding the Git model. It's not an easy process, you can't do it in a few hours. But if you don't do the learning, there's hardly any point to using Git at all. If all you want is a distributed VCS with a clean design and familiar model, use Mercurial, which you can learn in a few hours. This is why the MercurialEclipse plugin can fit the existing Eclipse Team design without too much of a stretch: add a layer for push/pull and some support for patch queues, and you're done.
So let's take it as given that a development team chooses Git because they want all the new features it provides, and that the members of the team have done what they have to in order use Git effectively. At minimum they've sat through Chacon's course and/or read his book, and they've spent a week or two using command-line Git daily for practice. Now they want to start using Git in Eclipse. What do they want to see?
In my experience they certainly would like to see uniformity with the other Team plugins they already know. Good Team integration is definitely a goal worth striving for. But they require uniformity with command-line Git. This is essential. Having spent the time learning the ins and outs of a complicated VCS model with lots of useful new features, they want ready and 'natural' access to those features. They're already thinking and speaking in Git at this point. They have to be to understand what those features are and how to use them. Now they want to get at as many of them as they can in EGIT. If this is made difficult or convoluted, that's a much nastier form of frustration, since it never gets better (unlike the initial frustration of using Git before you understand it).
For the easy parts of Git, EGIT can and already does integrate nicely both with Team and with Git. For for the more interesting parts, the parts that led to the choice of Git in the first place, there's unfortunately a trade-off. One of the two forms of integration has to take precedence and in my view the precedence has to be with Git, not Team. Otherwise you end up with something like IDEA's Git plugin: simple, integrated with IDEA's existing VCS views, and a pain in the neck every day for experienced Git users.
[Updated on: Sun, 02 October 2011 14:44] Report message to a moderator
|
|
| | |
Re: Make egit 'Checkout' match egit 'Switch to' [message #731695 is a reply to message #731643] |
Sun, 02 October 2011 14:44 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
What Mr Hermann calls a "strange tendency" is to me simple observation: watch new users of Git, note where they get confused or frustrated, whether it's with egit, cli Git, git-gui or TortoiseGit. It will quickly become apparent that they run into trouble because they're trying to use Git with a mental model that comes from CVS or SVN, in other words, the most frequently used Team plugins. I'm not talking about guru operations here, I'm talking about core Git, the twenty or so operation we all use regularly.
To minimize that confusion and frustration I think it's important that egit be consistent with the Git model, including terminology. Where it can also be consistent with other Team providers, that's great; there are many examples of this already in egit. Where it can't, and a choice has to be made, better to stay consistent with Git than with Subclipse (say). There are also examples of this already in egit.
As you see, I'm not suggesting a change in direction, quite the contrary. The egit team is already implicitly following this consistency rule. Really my suggestion is only that it be made more explicit and applied where needed in the few places now where it isn't, and also kept in mind as egit is extended to cover more features of Git, features that will be even further removed from CVS and SVN.
|
|
| |
Re: Make egit 'Checkout' match egit 'Switch to' [message #732021 is a reply to message #731961] |
Mon, 03 October 2011 17:42 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
R Shapiro wrote on Mon, 03 October 2011 16:55Another point worth mentioning in response to this earlier comment:
> Eventually there will be more users learning Git through EGit than those
> who learned Git before we had EGit.
Not all Git users of any given repository will be using Eclipse. Even on a single team, some might be using another IDE with its own Git plugin (IDEA, XCode), others might be using Eclipse for development but some other tool for Git operations (GitX, GitK/Git Gui.Tortoise). If everyone is viewing Git though the lens of their preferred plugin or tool, and if these tools aren't all using the same set of terms to mean the same thing, that's a major problem.
Conversely, you might well find yourself in a situation where project A requires you to use Eclipse and EGIT and project B requires you to use IDEA and its Git plugin. This is no problem at all if you know Git itself and if the plugins clearly follow the standard Git model and terminology. It's a significant problem otherwise.
It's all true. There are so many scenarios, so many different users with different expectations, understanding, habits, languages. All want smooth transitions. I'm just saying that one of these groups will be those that don't speak Git CLI, and I expect that group to be growing fast. But I don't know the future.
Back to the details: in EGit 1.1 I still see several occurrences of "Checkout" and "Switch to" each. We all agree that this should be unified, don't we? The question is only, which one to pick, right?
For the records: I'm still in favor of "Switch to".
However, there's another recurring issue in these menu commands: what actually is the sentence we are saying by clicking here?
A similar example: what exactly are we saying with these actions:
- "Rebase"
- "Rebase on top of"
- "Rebase ..."
I'm not a usability expert but I'd expect that those actions could be expanded to sentences like
"Rebase the current workspace from latest commits from stream X"
or shorter:
"Rebase workspace from X"
I can understand that for "Rebase ...", "X" will be inserted by the wizard.
However, for all variants, I think developers could use some help, that the selected item is not the one being modified, but the one to fetch updates from, right? From all I can tell, this is not the most common way of using context menu actions. How about "Rebase from" (with or without "...")?
cheers,
Stephan
|
|
|
Re: Make egit 'Checkout' match egit 'Switch to' [message #732072 is a reply to message #732021] |
Mon, 03 October 2011 20:54 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
Stephan Herrmann skrev 2011-10-03 19.42:
> R Shapiro wrote on Mon, 03 October 2011 16:55
>> Another point worth mentioning in response to this earlier comment:
>>
>>
>> > Eventually there will be more users learning Git through EGit than
>> those
>> > who learned Git before we had EGit.
>>
>>
>> Not all Git users of any given repository will be using Eclipse. Even
>> on a single team, some might be using another IDE with its own Git
>> plugin (IDEA, XCode), others might be using Eclipse for development
>> but some other tool for Git operations (GitX, GitK/Git Gui.Tortoise).
>> If everyone is viewing Git though the lens of their preferred plugin
>> or tool, and if these tools aren't all using the same set of terms to
>> mean the same thing, that's a major problem.
>>
>> Conversely, you might well find yourself in a situation where project
>> A requires you to use Eclipse and EGIT and project B requires you to
>> use IDEA and its Git plugin. This is no problem at all if you know Git
>> itself and if the plugins clearly follow the standard Git model and
>> terminology. It's a significant problem otherwise.
>
>
> It's all true. There are so many scenarios, so many different users with
> different expectations, understanding, habits, languages. All want
> smooth transitions. I'm just saying that one of these groups will be
> those that don't speak Git CLI, and I expect that group to be growing
> fast. But I don't know the future.
>
> Back to the details: in EGit 1.1 I still see several occurrences of
> "Checkout" and "Switch to" each. We all agree that this should be
> unified, don't we? The question is only, which one to pick, right?
>
> For the records: I'm still in favor of "Switch to".
Holding a short while more to see if the person that changed one of the
occurrences instead of all before changing any more :). Switch to has
the advantage that it does not conflict with a git term. Meanwhile I
think we can continue to discuss terminology and change more than one
place in a consistent manner.
> However, there's another recurring issue in these menu commands: what
> actually is the sentence we are saying by clicking here?
> A similar example: what exactly are we saying with these actions:
> - "Rebase"
> - "Rebase on top of"
> - "Rebase ..."
>
> I'm not a usability expert but I'd expect that those actions could be
> expanded to sentences like
> "Rebase the current workspace from latest commits from stream X"
> or shorter:
> "Rebase workspace from X"
Long menu names tend to cause usability problems on their own, but the
other suggestion is ok in length. Workspace might be misleading though,
since we don't rebase the whole workspace, but the branch in the
repository containing the selected project. That's a very long menu name
though so I invite more suggestions before changing anything.
> I can understand that for "Rebase ...", "X" will be inserted by the wizard.
> However, for all variants, I think developers could use some help, that
> the selected item is not the one being modified, but the one to fetch
> updates from, right? From all I can tell, this is not the most common
> way of using context menu actions. How about "Rebase from" (with or
> without "...")?
"Rebase from" confuses me. You rebase a branch by moving it's commits on
top of something. For most, but not all, cases the top-of-what is
implicit as the tool figures it out.
Rebase might be the bad term, but it seems it is the established name in
those SCM's that support the feature, so we have at least a set of
users that understand it.
We could add tooltips with longer explanations.
Some suggestions without thinking too much...
[Project explorer]
Rebase... (indicates there is a dialog coming up hence it's safe and
the folling dialog provides a little more help, could have more...)
[History]
Rebase current branch here
[Repository view]
Rebase current branch here
-- robin
|
|
|
Re: Make egit 'Checkout' match egit 'Switch to' [message #732102 is a reply to message #732072] |
Mon, 03 October 2011 22:32 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Robin Rosenberg wrote on Mon, 03 October 2011 22:54> However, there's another recurring issue in these menu commands: what
> actually is the sentence we are saying by clicking here?
> A similar example: what exactly are we saying with these actions:
> - "Rebase"
> - "Rebase on top of"
> - "Rebase ..."
>
> I'm not a usability expert but I'd expect that those actions could be
> expanded to sentences like
> "Rebase the current workspace from latest commits from stream X"
> or shorter:
> "Rebase workspace from X"
Long menu names tend to cause usability problems on their own, but the
other suggestion is ok in length.
Sorry, I wasn't clear: I didn't mean to spell it out in the menu but the action name should give clues to the user how to spell it out in their minds. E.g., a drag-and-drop directly maps from "move this from here to there". Actions in context menus only have one explicit object and if the object used by the action isn't even exactly the one I'm pointing at, and another one will be figured out from the context, too, that's many implicit things that leave a new user wondering what he is saying.
Quote: Workspace might be misleading though,
since we don't rebase the whole workspace, but the branch in the
repository containing the selected project. That's a very long menu name
though so I invite more suggestions before changing anything.
I'm happy I brought this up, because that is really a complex specification of what will be updated. That's what I mean with "many implicit things". Just as feedback from a user with < 1 week of EGit (and no git before): as I wasn't 100% sure what the different occurrences of that menu action would do, I felt safest pointing at a remote branch in the repositories view and invoking Rebase from there.
Quote:"Rebase from" confuses me. You rebase a branch by moving it's commits on
top of something.
Sorry, if confusing. I was maybe too much thinking of Rebase as a more explicit variant of Pull, and I certainly want to Pull from somewhere.
Quote:[Project explorer]
Rebase... (indicates there is a dialog coming up hence it's safe and
the folling dialog provides a little more help, could have more...)
[History]
Rebase current branch here
[Repository view]
Rebase current branch here
I think s.t. like this would help.
Another thing as you mentioned "the branch in the repository containing the selected project": I had the impression that in the package explorer when selecting multiple projects from the same repo some menu actions disappear which shouldn't actually. Why should multi select hide menu actions?
cheers,
Stephan
|
|
|
Re: Make egit 'Checkout' match egit 'Switch to' [message #732322 is a reply to message #732102] |
Tue, 04 October 2011 13:58 |
R Shapiro Messages: 386 Registered: June 2011 |
Senior Member |
|
|
The "on top of" language in the Rebase toolbar item's tooltip has definitely puzzled folks here. Personally I hear "rebase to" most often, following the pattern of "reset to". But ProGit has "rebase onto", and that book is as close to a standard reference as there is.
As for checkout, EGIT currently supports Git 'checkout' with two different commands: "Checkout" (aka "Switch To") and one use of "Replace With". At the same time, other uses of "Replace With" are more like one of the variants of Git 'reset', not 'checkout'. So aside from simple naming variants of one EGIT operation, we also have one Git operation mapped to two different EGIT operations, and vice-versa.
Seems like we need at minimum a table that shows all the operation mappings and naming variants. If there isn't one yet, I'll volunteer to write one.
[Updated on: Tue, 04 October 2011 16:26] Report message to a moderator
|
|
|
Re: Make egit 'Checkout' match egit 'Switch to' [message #733431 is a reply to message #732102] |
Tue, 04 October 2011 06:38 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
Stephan Herrmann skrev 2011-10-04 00.32:
> Robin Rosenberg wrote on Mon, 03 October 2011 22:54
>> > However, there's another recurring issue in these menu commands: what
>> > actually is the sentence we are saying by clicking here?
>> > A similar example: what exactly are we saying with these actions:
>> > - "Rebase"
>> > - "Rebase on top of"
>> > - "Rebase ..."
>> >
>> > I'm not a usability expert but I'd expect that those actions could be
>> > expanded to sentences like
>> > "Rebase the current workspace from latest commits from stream X"
>> > or shorter:
>> > "Rebase workspace from X"
>>
>> Long menu names tend to cause usability problems on their own, but the
>> other suggestion is ok in length.
>
>
> Sorry, I wasn't clear: I didn't mean to spell it out in the menu but the
> action name should give clues to the user how to spell it out in their
> minds. E.g., a drag-and-drop directly maps from "move this from here to
> there". Actions in context menus only have one explicit object and if
> the object used by the action isn't even exactly the one I'm pointing
> at, and another one will be figured out from the context, too, that's
> many implicit things that leave a new user wondering what he is saying.
>
> Quote:
>> Workspace might be misleading though, since we don't rebase the whole
>> workspace, but the branch in the repository containing the selected
>> project. That's a very long menu name
>> though so I invite more suggestions before changing anything.
>
>
> I'm happy I brought this up, because that is really a complex
> specification of what will be updated. That's what I mean with "many
> implicit things". Just as feedback from a user with < 1 week of EGit
> (and no git before): as I wasn't 100% sure what the different
> occurrences of that menu action would do, I felt safest pointing at a
> remote branch in the repositories view and invoking Rebase from there.
>
> Quote:
>> "Rebase from" confuses me. You rebase a branch by moving it's commits
>> on top of something.
>
>
> Sorry, if confusing. I was maybe too much thinking of Rebase as a more
> explicit variant of Pull, and I certainly want to Pull from somewhere.
Rebase as an option to pull came much later than pull. Pull was the
original command in git to pull from a remote repository. Later it was
split into fetch and merge. Pull as in fetch + merge is quite convenient
to it stays. Even later it was recognized that some people (a lot of
people actuall) never merge after fetch so a rebase (as opposed to
merge) was added. Default for pull is merge, but the default can be
changed for a branch. EGit only has an UI to change this when creating
a branch to track a remote branch. It can be changed later, but
currently only by editing the config file.
> Quote:
>> [Project explorer]
>> Rebase... (indicates there is a dialog coming up hence it's safe and
>> the folling dialog provides a little more help, could have more...)
>>
>> [History]
>> Rebase current branch here
>>
>> [Repository view]
>> Rebase current branch here
>
>
> I think s.t. like this would help.
>
> Another thing as you mentioned "the branch in the repository containing
> the selected project": I had the impression that in the package explorer
> when selecting multiple projects from the same repo some menu actions
> disappear which shouldn't actually. Why should multi select hide menu
> actions?
Some operations would be considerably more complicated when operating
over more than one repository. Some could be considered somewhat
reasonable, like commit, reset, create branch, but even so they involve
so many special cases that it's not worth the effort to solve.
Actually I hate disappearing menus, they should be greyed out instead if
that is what confuses you (and me). It's really takes a toll when
you *thought* you knew when a menu was, but suddenly it's gone and you
no longer know if you are just looking in the wrong place. It might be
ok do hide a large set of menus, say all git related stuff, but not a
single command.
-- robin
|
|
| | |
Re: Make egit 'Checkout' match egit 'Switch to' [message #733497 is a reply to message #733444] |
Tue, 04 October 2011 21:51 |
Robin Rosenberg Messages: 332 Registered: July 2009 |
Senior Member |
|
|
Stephan Herrmann skrev 2011-10-04 20.28:
> Robin Rosenberg wrote on Tue, 04 October 2011 08:38
>> > Another thing as you mentioned "the branch in the repository containing
>> > the selected project": I had the impression that in the package
>> explorer
>> > when selecting multiple projects from the same repo some menu actions
>> > disappear which shouldn't actually. Why should multi select hide menu
>> > actions?
>>
>> Some operations would be considerably more complicated when operating
>> over more than one repository. Some could be considered somewhat
>> reasonable, like commit, reset, create branch, but even so they involve
>> so many special cases that it's not worth the effort to solve.
>
>
> Even complex when all selected project are connected to the same repo?
> That's what I had: select 2 or 3 projects from the same repo, opened
> context menu, wondered where all the options had gone...
Not much, but a little more code to detect whether the operation is ok
or not and then testing it. Things like restricting an operation to only
one project can be done through a simple declaration in the plugins
manifest.
If you can compose of set of such inconsistencies and report at
bugs.eclipse.org, that would help in getting it fixed. Even better,
patches in Gerrit. One report/patch per inconsistent operation is
best.
-- robin
|
|
| | | |
Goto Forum:
Current Time: Tue Sep 24 07:15:25 GMT 2024
Powered by FUDForum. Page generated in 0.06824 seconds
|