Community
Participate
Working Groups
In order to fix the usability problems with the existing Sharing Wizard we should implement a new Sharing Wizard. This was discussed during the EGit hackaton and we came to the proposal described here. 1. Sharing projects located in the working directory of an existing Git repository Projects should be auto-shared by a resource change listener which shall trigger - when a new project is created or imported which is located under the working directory of a Git repository known to the Eclipse workbench. - in order to prevent that we miss projects created or imported before EGit bundles are active we need to scan the existing projects when the org.eclipse.egit.core bundle gets activated 2. Explicit sharing of projects using the new wizard - First wizard page - allows to select the repository the selected projects should be shared with - we can reuse the first page of the existing "Import... > Git > Projects from Git" wizard - add a "Create..." button into that wizard page that opens a dialog to enable creation of a new local repository - Second wizard page - similar to the CVS Sharing Wizard this page allows to specify where the selected projects should be located relative to the repository's working directory
Created attachment 202909 [details] First wizard page: select repository
Created attachment 202910 [details] Dialog: create new local repository
Created attachment 202911 [details] Second wizard page: select relative path in working dir
(In reply to comment #0) > Projects should be auto-shared by a resource change listener which > shall trigger > - when a new project is created or imported which is located under the > working directory of a Git repository known to the Eclipse workbench. > - in order to prevent that we miss projects created or imported before > EGit bundles are active we need to scan the existing projects when > the org.eclipse.egit.core bundle gets activated This doesn't sound like a good idea, at least not with a preference option to disable this feature. I have repeatedly created a Git repository in the source tree of a legacy SCM (like CVS, Perforce,...), and I would prefer if this great way of adding missing functionality to legacy SCMs isn't broken.
(In reply to comment #0) > Projects should be auto-shared by a resource change listener which > shall trigger I don't think the other SCM plug-ins do this and like Tobias am against this proposal.
(In reply to comment #4) > (In reply to comment #0) > > Projects should be auto-shared by a resource change listener which > > shall trigger > > - when a new project is created or imported which is located under the > > working directory of a Git repository known to the Eclipse workbench. > > - in order to prevent that we miss projects created or imported before > > EGit bundles are active we need to scan the existing projects when > > the org.eclipse.egit.core bundle gets activated > > This doesn't sound like a good idea, at least not with a preference option to > disable this feature. I have repeatedly created a Git repository in the source > tree of a legacy SCM (like CVS, Perforce,...), and I would prefer if this great > way of adding missing functionality to legacy SCMs isn't broken. We could provide a preference to switch auto-sharing off for such cases. Also we should check that projects are not yet shared with another team provider.
(In reply to comment #0) > Projects should be auto-shared by a resource change listener which > shall trigger > - when a new project is created or imported which is located under the > working directory of a Git repository known to the Eclipse workbench. This sounds intriguing indeed. However, I wonder how frequently this would actually happen once people follow our recommendations and default proposals for creating Repositories outside the Eclipse workspace. In that case, the change listener wouldn't find the Repository, so it would be pointless. Of course people may create the projects by manually changing the project location to some child folder of the working folder in their respective creation wizards (where available), but that sounds more cumbersome than the option to decide during sharing where to move the project location (IMHO). In case the project is in fact located under an existing Repository's working folder (either because the Repo is in the workspace or because people have carefully crafted the project location), then I think the wizard should be smart enough to auto-detect this situation and suggest that Repository and the project's location as default (I know, it will be quite ugly to do a good UI for this once this is supposed to work for multi project selection). Still the user would have to hit "Team->Share" and I agree with Tobias and Remy here when it comes to do this automagically. > 2. Explicit sharing of projects using the new wizard I like the "screenshots". Perhaps the first screen should (rather prominently) indicate if an existing Repository is a parent of the project, but we shouldn't restrict the user from chosing another Repository.
Auto-sharing of projects was implemented with commit e20c835071615cd81ceb3e150f5a75c0db4ebf51
