Community
Participate
Working Groups
If a Root folder in a repository has a .project file, and it it's children folders also may have .project files. eGit only shows the root .project folder to import. This does not happen with say smartGit or another alternative git tool. Ideally, we would have something like the CVS Repository explorer that would allow for selction of what projects to check out from a repository. For a sample repository to test with you can try the WTP readonly repository: git://dev.eclipse.org/org.eclipse.webtools/sourceediting.git
(In reply to comment #0) Hi Dave, this behaves exactly as the "Import Existing Projects" wizard (which in turn assumes that nesting of projects does not make sense). Could you elaborate a bit on the use case here? Also, could you point me to a specific location in your repository to look at? Thanks and best regards Mathias
(In reply to comment #1) > (In reply to comment #0) > > Hi Dave, > this behaves exactly as the "Import Existing Projects" wizard (which in turn > assumes that nesting of projects does not make sense). > Could you elaborate a bit on the use case here? Also, could you point me to a > specific location in your repository to look at? > Thanks and best regards > Mathias Best one to take a look at is the WTP Source Editing projects git repository. git://dev.eclipse.org/org.eclipse.webtools/sourceediting.git It's been a little bit since I tried this but one way to replicate the issue is the following. Create a new git repository, in the root, have a .project file, create some sub folders like sourceediting/plugins/org.eclipse.wst.xsl Put a .project in the org.eclipse.wst.xsl The last time I tested this I only saw the root project not child project.
(In reply to comment #2) > > Best one to take a look at is the WTP Source Editing projects git repository. > > git://dev.eclipse.org/org.eclipse.webtools/sourceediting.git > > It's been a little bit since I tried this but one way to replicate the issue is > the following. Create a new git repository, in the root, have a .project file, > create some sub folders like sourceediting/plugins/org.eclipse.wst.xsl > > Put a .project in the org.eclipse.wst.xsl > > The last time I tested this I only saw the root project not child project. As I tried to point out above, this works as designed. I still fail to understand why you would have folders containing a .project-file as child (be it direct or not) of another folder also containing a .project file. IMHO nesting of projects into each other makes no sense. Could you please confirm that such nesting is actually needed for your use case? Also, I have now cloned your repository, but I still don't know where to look for such a situation. Please point me to some location (I have checked out the "origin" branch where you use nested projects.
(In reply to comment #3) > As I tried to point out above, this works as designed. I still fail to > understand why you would have folders containing a .project-file as child (be > it direct or not) of another folder also containing a .project file. IMHO > nesting of projects into each other makes no sense. > > Could you please confirm that such nesting is actually needed for your use > case? Actually, I have no control over the structure of the repository, as this was the way it was converted from CVS. See the original CVS repository for where the structure came from. While I understand that this may be by design, it will be a potential issue as projects migrate their existing content to git. > Also, I have now cloned your repository, but I still don't know where to look > for such a situation. Please point me to some location (I have checked out the > "origin" branch where you use nested projects. I'm cloning now...I'll see if the issue still exists, as we may have deleted the offending .project file.
I can reproduce this with the current eGit builds...while I suspect this might be an issue with the Import Existing Projects wizard, it is also a usability issue when repositories have been migrated from the existing CVS to git. The way I can produce this is: 1. clone the webtools sourceediting repository, bring in the Master branch only. 2. Make sure import projects is checked. 3. When the clone finishes, it will only show one project, the sourceeding project. However this is not what is wanted. As the sourceediting project is the parent for all the actual projects. It just happens to have a .project file in there. The actual projects reside under sourceediting/plugins, sourceediting/features. The work around is to just clone the repository, and then use the Import Existing projects wizard to manually bring these projects into the workspace. Ideally, it would be nice to have an option to browse the cloned Git repo and then bring these in. Hopefully that is what the git repository explorer will allow.
The only issue with the work around is that the eGit team features aren't enabled once you import the projects.
(In reply to comment #6) > The only issue with the work around is that the eGit team features aren't > enabled once you import the projects. Ok, I see the point now... I guess what we need to do here is to be a bit more flexible when it comes to using the "Import Existing Projects" wizard. I am actually working on bug 301168 which is about adding a "Git Repositories" view. With that view, you will be able to right-click on the repository node and select "Import Existing Projects" which will start the well-known wizard. By default, the working directory of the Git repository will be selected as directory, but you can use the "Browse..." button to switch to some other directory and find projects there. Project sharing is done in the background after the import by detecting new projects in the workspace and sharing them automatically. Let me know if this is good enough for your use case (you may want to wait for the repositories view to be in the master branch)...
(In reply to comment #7) > (In reply to comment #6) > > The only issue with the work around is that the eGit team features aren't > > enabled once you import the projects. > > Ok, I see the point now... I guess what we need to do here is to be a bit more > flexible when it comes to using the "Import Existing Projects" wizard. > I am actually working on bug 301168 which is about adding a "Git Repositories" > view. With that view, you will be able to right-click on the repository node > and select "Import Existing Projects" which will start the well-known wizard. > By default, the working directory of the Git repository will be selected as > directory, but you can use the "Browse..." button to switch to some other > directory and find projects there. That is fine. > > Project sharing is done in the background after the import by detecting new > projects in the workspace and sharing them automatically. If we are talking about sharing the imported projects then I think that is fine. If we are talking about sharing new projects automatically that may be more problematic. As in my case it's not unusual to have projects from CVS, and SVN checked out into the same workspace. > Let me know if this is good enough for your use case (you may want to wait for > the repositories view to be in the master branch)... Yeah, I'm monitoring the repositories explorer issue as well so will test this out once that is in place.
(In reply to comment #8) > > If we are talking about sharing the imported projects then I think that is > fine. If we are talking about sharing new projects automatically that may be > more problematic. As in my case it's not unusual to have projects from CVS, > and SVN checked out into the same workspace. > Yes, this would only be done with the imported projects.
I believe that this can be closed: with the Git Repositories View, it is now possible to start the Git Import Project wizard on an arbitrary subdirectory of the working tree. So if you start it on the working directory root node itself, you would only see the outermost project. If you want to import nested projects, you could start the import wizard from a sub-folder, e.g. /plugins to see all the projects within this folder. This exactly works as the well-known "Import Existing Projects into Workspace" wizard.
Since EGit 2.2, it's also possible to import nested projects when the root project was selected see bug 396067 (changed from WONTFIX to FIXED).
