Community
Participate
Working Groups
I'm working with my converted platform ui test repo, git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git I have it cloned, on master, and import my projects. When I checkout origin/R3_7_maintenance a number of my org.eclipse.e4.ui.* project disappear (that makes sense, they don't exist in R3_7_maintenance, it's before the merge). When I switch back to master, however, the projects don't come back. This presents a bit of a problem as it's about 18 projects. PW
This seems like a major stumbling block to me. I can't stash my work, checkout and deliver a Indigo SR1 fix, and switch back unstash my work. I have to have one git repo clone and one workspace per branch (3 branches in this case). PW
Switching branches causes one dialog popup per project that disappears. That means you need to dismiss 18 dialogs before you can even try to fix the problem. PW
Switching from R4_development to master for 4.2 development just incurred this bug again ... extremely painful. PW
I agree that it is unexpected and annoying, it happened to me as well. But I am not sure if it straightforward how to deal with it though considering that not all of projects could be open to begin with. Consider: 1. I am normally working opening a subset of projects of a repository. 2. When switching to another branch projects which are not there disappear which is expected. 3. When switching back I really expect all and only projects I had open at step 1 get back. Hmm, should egit memorize the list of open projects for each branch?
This affected several users at an EGit Tutorial today at EclipesCon Europe. I think EGit should track imported projects on a per-branch basis and restore missing projects when needed.
(In reply to comment #4) > 3. When switching back I really expect all and only projects I had open at step > 1 get back. Hmm, should egit memorize the list of open projects for each > branch? I would only expect EGit to track what it had already opened for that workspace, since you're right, you wouldn't want a checkout and a switch back to suddenly import projects you ignored the first time. The info could be stored in the IDialogSettings or an IMemento in the plugin state location, as a preference "Imported Projects" or as properties on the workspace root (although the first 2 options are probably easiest). If git was asked to import it, it could stay in the list and be checked on every switch/checkout until the user deletes the project from their workspace. PW
I think EGit should not magically remove and/or add projects when I switch branches. I e.g. like to keep projects from a repo organized in a working set (bug 358937). If you just delete and restore projects, they will be missing from working sets. A better solution would be to just close a project when it is not available in the new branch. You could even get away without storing any project references in EGit: When switching to another branch, just open all closed projects that were not available in the old branch but are available in the new branch. (Do not touch projects that are available in both or neither of the branches.)
(In reply to comment #7) > A better solution would be to just close a project when it is not available in > the new branch. I like this approach, if EGit can get to the projects before core.resources refreshes and decides that those projects are invalid/broken. PW
(In reply to comment #8) > (In reply to comment #7) > > A better solution would be to just close a project when it is not available in > > the new branch. This does not really solves the problem described in comment 4 as you end up with closed projects after switching back and have to be aware to reopen them. If there are other closed projects in workspace it is easy to lose the track.
(In reply to comment #9) > This does not really solves the problem described in comment 4 as you end up > with closed projects after switching back and have to be aware to reopen them. > If there are other closed projects in workspace it is easy to lose the track. No, please read the whole comment 7. The only case that proposal doesn't cover are projects that are only available in one branch and that are closed. After switching to another branch and back, they will be reopened.
(In reply to comment #10) > (In reply to comment #9) > > This does not really solves the problem described in comment 4 as you end up > > with closed projects after switching back and have to be aware to reopen them. > > If there are other closed projects in workspace it is easy to lose the track. > No, please read the whole comment 7. The only case that proposal doesn't cover > are projects that are only available in one branch and that are closed. After > switching to another branch and back, they will be reopened. Well that still does not restore exact initial status cleanly, you just mitigated the issue. It is not uncommon to keep closed projects in workspace. Even if it is easier to re-close than re-import, still annoying.
(In reply to comment #7) > A better solution would be to just close a project when it is not available in > the new branch. The closed projects could not be opened though while on the new branch since their is no .project file in the working directory.
Proposed fix pushed to: http://egit.eclipse.org/r/#change,4931 * Projects missing on branches being checked out are closed instead of deleted * Projects previously open on branches being checked out are reopened
merged as 1e979c497f4c7b979f5fd95a7a970946add860eb
I verified it in 1.3.0.201201172015. It works under normal conditions but if a project deletion happens in a branch then we end up with a ghost project. Filed bug 368976 to track that.
*** Bug 337581 has been marked as a duplicate of this bug. ***
