Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EGit » 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 Go to next message
R Shapiro is currently offline 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 #724858 is a reply to message #692972] Tue, 13 September 2011 11:10 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 386
Registered: June 2011
Senior Member
Thanks to the development team for adding this feature - it appeared in yesterday's nightly build and I've already made good use of it. The new dialog Includes branch deletion and renaming as well, nice extras I hadn't thought of.

Now all the day-to-day branch management (and these are literally daily operations) is in one place easily accessible from the main menubar. Excellent.




Re: Make egit 'Checkout' match egit 'Switch to' [message #730213 is a reply to message #724858] Tue, 27 September 2011 22:20 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
When selecting a branch (repository view) or a commit (history view) I still see the "Checkout" command.

I see a difference in gestures (here we already know what exactly to switch to), but isn't the action the same?

For people coming from CVS/SVN "Checkout" suggests what only "Import Projects..." fulfills.

During my very first steps with EGit this naming still (using EGit 1.1.0) got me quite confused.

Stephan
Re: Make egit 'Checkout' match egit 'Switch to' [message #730462 is a reply to message #730213] Wed, 28 September 2011 13:04 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 386
Registered: June 2011
Senior Member
You're right that the term 'checkout' is semantically different in Git as compared with CVS and SVN. That terminology difference wasn't really my concern here though. I was more interested in unifying two aspects of the egit gui that were doing very similar but not quite identical things. This has mostly been accomplished.

Although I wasn't much concerned with the names of the operations for the first round, maybe that could be looked at as a second step. In particular, although Git 'checkout' in one of its variants is like SVN 'switch' in one its variants, Git has no operation called 'switch'. For that reason the remaining references in egit to 'Switch to' should probably be changed to 'Checkout' for consistency.

Re: Make egit 'Checkout' match egit 'Switch to' [message #730985 is a reply to message #730462] Thu, 29 September 2011 16:23 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
R Shapiro wrote on Wed, 28 September 2011 15:04

[...] For that reason the remaining references in egit to 'Switch to' should probably be changed to 'Checkout' for consistency.


I was suggesting the opposite Smile, rename remaining 'Checkout's to 'Switch to', but if the EGit documentation provides, e.g., a dictionary for users coming from other VCS the effect will be similar. The inconsistency is indeed the primary concern, translating between different parlance comes second - still very important, I'd say - "language barriers" can be quite frustrating.

Stephan
Re: Make egit 'Checkout' match egit 'Switch to' [message #731011 is a reply to message #730985] Thu, 29 September 2011 17:02 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
Registered: July 2009
Senior Member
Stephan Herrmann skrev 2011-09-29 18.23:
> R Shapiro wrote on Wed, 28 September 2011 15:04
>> [...] For that reason the remaining references in egit to 'Switch to'
>> should probably be changed to 'Checkout' for consistency.
>
>
> I was suggesting the opposite :), rename remaining 'Checkout's to
> 'Switch to', but if the EGit documentation provides, e.g., a dictionary
> for users coming from other VCS the effect will be similar. The
> inconsistency is indeed the primary concern, translating between
> different parlance comes second - still very important, I'd say -
> "language barriers" can be quite frustrating.

The direction is to use the same terminology as other team providers.

Maybe we should translate :)

en_US for Eclipse terminology
en_US_Git for Git terminology

-- robin
Re: Make egit 'Checkout' match egit 'Switch to' [message #731022 is a reply to message #731011] Thu, 29 September 2011 17:48 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Robin Rosenberg wrote on Thu, 29 September 2011 19:02
The 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 Very Happy

Stephan
Re: Make egit 'Checkout' match egit 'Switch to' [message #731267 is a reply to message #731022] Fri, 30 September 2011 13:06 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 386
Registered: June 2011
Senior Member
You can thank Linus for this particular Babel Smile 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 #731601 is a reply to message #731267] Sun, 02 October 2011 00:43 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
I'm seeing a strange tendency to say in order to grok Git you first need a brainwash an then to spend weeks or more hacking on the command line. I see a chance that EGit could support a different road: start with Git-light by simply clicking on the same icons you've seen from other Team providers. After you're confident you master the basic steps you may become curious what else is there.

Eventually there will be more users learning Git through EGit than those who learned Git before we had EGit.

Difficulties during the first steps of learning EGit will effect very many users.

Difficulties in mapping guru-details between EGit and Git CLI will affect fewer users.

Getting a smooth transition from Git-light with EGit to mastering all the details would be a real treat, but that surely isn't a piece of cake. Just, without consistency all users will be confused Razz

best,
Stephan
Re: Make egit 'Checkout' match egit 'Switch to' [message #731643 is a reply to message #731601] Sun, 02 October 2011 07:59 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
Registered: July 2009
Senior Member
Stephan Herrmann skrev 2011-10-02 02.43:
> I'm seeing a strange tendency to say in order to grok Git you first need
> a brainwash an then to spend weeks or more hacking on the command line.
> I see a chance that EGit could support a different road: start with
> Git-light by simply clicking on the same icons you've seen from other
> Team providers. After you're confident you master the basic steps you
> may become curious what else is there.
>
> Eventually there will be more users learning Git through EGit than those
> who learned Git before we had EGit.
>
> Difficulties during the first steps of learning EGit will effect very
> many users.
>
> Difficulties in mapping guru-details between EGit and Git CLI will
> affect fewer users.
>
> Getting a smooth transition from Git-light with EGit to mastering all
> the details would be a real treat, but that surely isn't a piece of
> cake. Just, without consistency all users will be confused :p

I'm not sure what kind of action your opinion should result in. It's all
in the details. Consistent with what? If you mean consistency within
itself, then that is probably a no-brainer for most cases, i.e. the
exact same operation should behave the same and have the same name.

-- robin
Re: Make egit 'Checkout' match egit 'Switch to' [message #731695 is a reply to message #731643] Sun, 02 October 2011 14:44 Go to previous messageGo to next message
R Shapiro is currently offline 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 #731961 is a reply to message #731695] Mon, 03 October 2011 14:55 Go to previous messageGo to next message
R Shapiro is currently offline R Shapiro
Messages: 386
Registered: June 2011
Senior Member
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.
Re: Make egit 'Checkout' match egit 'Switch to' [message #732021 is a reply to message #731961] Mon, 03 October 2011 17:42 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
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".

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 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
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 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
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 Go to previous messageGo to next message
R Shapiro is currently offline 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 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
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 #733444 is a reply to message #733431] Tue, 04 October 2011 18:28 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
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...

Stephan
Re: Make egit 'Checkout' match egit 'Switch to' [message #733445 is a reply to message #733431] Tue, 04 October 2011 18:33 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Robin Rosenberg wrote on Tue, 04 October 2011 08:38
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.


wouldn't it be most convenient if a workspace default would let you set the default to be used for each newly created / checked-out branch?

Now I have to remember checking "rebase" on each of these operations.

best,
Stephan

Re: Make egit 'Checkout' match egit 'Switch to' [message #733497 is a reply to message #733444] Tue, 04 October 2011 21:51 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
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
Re: Make egit 'Checkout' match egit 'Switch to' [message #733499 is a reply to message #733445] Tue, 04 October 2011 21:53 Go to previous messageGo to next message
Robin Rosenberg is currently offline Robin Rosenberg
Messages: 324
Registered: July 2009
Senior Member
Stephan Herrmann skrev 2011-10-04 20.33:
> Robin Rosenberg wrote on Tue, 04 October 2011 08:38
>> 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.
>
>
> wouldn't it be most convenient if a workspace default would let you set
> the default to be used for each newly created / checked-out branch?
>
> Now I have to remember checking "rebase" on each of these operations.

It's right in front of your nose, so it's not *that* hard to remember,
but I won't argue against it. I'll be happy to press Submit on a patch
that fixes this.

-- robin
Re: Make egit 'Checkout' match egit 'Switch to' [message #734130 is a reply to message #731695] Thu, 06 October 2011 19:45 Go to previous messageGo to next message
John J. Franey is currently offline John J. Franey
Messages: 55
Registered: July 2009
Member
I tripped over this discussion looking for something else, but HAD to drop a note because to me, obfuscating the git concepts with a svn overlay is a concerns me. I left svn behind, and haven't touched it for 2-3 years. In order for me to use an svn overlay (or can we say, an svn flavored porcelain in egit), I would have to reacquaint myself with svn concepts and meanings. No thanks.

I'm familiar enough with the eclipse architecture to know that plugins could be used to implement different porcelain flavors. The discussion should not be about which 'porcelain' to implement, but which should be implemented first (by the qualified egit developers in their limited time.)

If I could influence the decision, I would vote for an egit porcelain that is closest to the unix git command line. I am not voting for the absence of an svn-like egit procelain, I could see its value for those from svn space. I just don't want to use it.
Re: Make egit 'Checkout' match egit 'Switch to' [message #734794 is a reply to message #733445] Sun, 09 October 2011 23:35 Go to previous message
Matthias Sohn is currently offline Matthias Sohn
Messages: 580
Registered: July 2009
Senior Member
Stephan Herrmann wrote on Tue, 04 October 2011 14:33
Robin Rosenberg wrote on Tue, 04 October 2011 08:38
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.


wouldn't it be most convenient if a workspace default would let you set the default to be used for each newly created / checked-out branch?

Now I have to remember checking "rebase" on each of these operations.

best,
Stephan



See [1]:

"EGit supports the git configuration parameter "branch.autosetuprebase", set it to "always" if you want to use the rebase pull strategy by default. If you set this in the repository configuration this is used for all local branches created based on a remote tracking branch in this repository, if you set it in your user configuration it will be used for all your repositories."

[1] http://wiki.eclipse.org/EGit/User_Guide#Branch_Creation_Dialog
Previous Topic:egit does not save upstream location
Next Topic:Why dont changes reflect in actual repository files?
Goto Forum:
  


Current Time: Wed Sep 24 04:46:29 GMT 2014

Powered by FUDForum. Page generated in 0.03380 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software