Community
Participate
Working Groups
Trying to import a repo from Github [0], I get a ITE. java.lang.reflect.InvocationTargetException at org.eclipse.egit.core.op.CloneOperation.run(CloneOperation.java:130) at org.eclipse.egit.ui.internal.clone.GitCloneWizard$2.run(GitCloneWizard.java:178) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Caused by: java.lang.NullPointerException at org.eclipse.jgit.lib.GitIndex$Entry.<init>(GitIndex.java:435) at org.eclipse.jgit.lib.GitIndex.addEntry(GitIndex.java:847) at org.eclipse.jgit.lib.WorkDirCheckout$1.visitEntry(WorkDirCheckout.java:183) at org.eclipse.jgit.lib.IndexTreeWalker.finishVisitTree(IndexTreeWalker.java:199) at org.eclipse.jgit.lib.IndexTreeWalker.walk(IndexTreeWalker.java:136) at org.eclipse.jgit.lib.IndexTreeWalker.walk(IndexTreeWalker.java:114) at org.eclipse.jgit.lib.WorkDirCheckout.checkoutOutIndexNoHead(WorkDirCheckout.java:167) at org.eclipse.jgit.lib.WorkDirCheckout.checkout(WorkDirCheckout.java:144) at org.eclipse.egit.core.op.CloneOperation.doCheckout(CloneOperation.java:227) at org.eclipse.egit.core.op.CloneOperation.run(CloneOperation.java:121) ... 2 more Root exception: java.lang.NullPointerException at org.eclipse.jgit.lib.GitIndex$Entry.<init>(GitIndex.java:435) at org.eclipse.jgit.lib.GitIndex.addEntry(GitIndex.java:847) at org.eclipse.jgit.lib.WorkDirCheckout$1.visitEntry(WorkDirCheckout.java:183) at org.eclipse.jgit.lib.IndexTreeWalker.finishVisitTree(IndexTreeWalker.java:199) at org.eclipse.jgit.lib.IndexTreeWalker.walk(IndexTreeWalker.java:136) at org.eclipse.jgit.lib.IndexTreeWalker.walk(IndexTreeWalker.java:114) at org.eclipse.jgit.lib.WorkDirCheckout.checkoutOutIndexNoHead(WorkDirCheckout.java:167) at org.eclipse.jgit.lib.WorkDirCheckout.checkout(WorkDirCheckout.java:144) at org.eclipse.egit.core.op.CloneOperation.doCheckout(CloneOperation.java:227) at org.eclipse.egit.core.op.CloneOperation.run(CloneOperation.java:121) at org.eclipse.egit.ui.internal.clone.GitCloneWizard$2.run(GitCloneWizard.java:178) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) org.eclipse.egit.feature.group: 0.8.0.201005262112 org.eclipse.jgit.feature.group: 0.8.0.201005241328 [0] http://github.com/lemmy/org.eclipse.ecf.discovery.dnssd
This is because we don't support submodules yet :(
*** Bug 306765 has been marked as a duplicate of this bug. ***
*** Bug 308452 has been marked as a duplicate of this bug. ***
We have added a meaningful error message to the Exception that is thrown when a repository with submodules is cloned using Egit. The change is http://egit.eclipse.org/r/#change,1083 and it was merged as 6e59e6dab963f2ae796a1e331a716fc7f4f9bfdd. However, until we implement this feature, there may be other issues if the repository that was cloned using an external tool is used within EGit.
Does the target milestone 0.9.0-M1 still stand and what is the ETA for M1?
(In reply to comment #5) > Does the target milestone 0.9.0-M1 still stand and what is the ETA for M1? Sorry, I should have changed this... I'm afraid we currently don't have anything in the pipeline for this, so we can't promise a target milestone at the moment.
*** Bug 324611 has been marked as a duplicate of this bug. ***
*** Bug 328914 has been marked as a duplicate of this bug. ***
When is this going to be implemented? This really creates some inconvenience when importing projects with submodules.
(In reply to comment #9) > When is this going to be implemented? This really creates some inconvenience > when importing projects with submodules. Nothing is explicitly planned at the moment. This would be a great bug for the community to step up and contribute something. http://wiki.eclipse.org/EGit/Contributor_Guide
*** Bug 346816 has been marked as a duplicate of this bug. ***
*** Bug 342892 has been marked as a duplicate of this bug. ***
Would love to see some movement on this issue to help improve some importing related options.
Seems more like a bug than a feature (semantics). Definite need!
This really is a serious, gaping hole in JGit's functionality. This prevents working with many bigger git projects.
+1 This bug has single handedly wiped the use of eclipse off of our tools used at our company, after having used it for years. Yes, the workaround is to use command line for all git commands, but when everyone is focusing on development -- why not just find a better tool. Please fix this as we have loved using eclipse and git till now.
I changed the dependencies to reflect the interpretation that this bug is about complete support now. We have partial support, i.e. you can clone repositories with submodules in them and you can commit. Working: - Clone - Push (nothing special here) - Commit (partial support) - Checkout to/from branches where state of submodule change. Notable missing support related to: - Updating the index with the latest commit from the submodule. Use the command line to stage the change. EGit commit can commit the state from the staged commit or the previous HEAD. - Renaming submodules. We have open issues related to project rename in general. - Merge/rebase: We need to figure out how to handle renames and conflicts as well as submodule/file conflicts for submodules - Create submodules - Update submodules from parent project state - Submodules within projects. This is somewhat exotic since we (I assume) rarely have submodules within projects. In most cases projects in submodules looks like a project in any other repo. Decorations of submodules within projects is undefined, but at least does not seem to break.
(In reply to comment #17) > - Submodules within projects. This is somewhat exotic since we (I assume) > rarely have submodules within projects. In most cases projects in submodules > looks like a project in any other repo. Decorations of submodules within > projects is undefined, but at least does not seem to break. You might need to clarify this, but the way I understand it is that you're saying sub-modules within a single workspace project is exotic/uncommon?? This is the exact functionality I'm waiting for. I want to be able to have a project hosted with GIT, which relies on submodules, which in my case will be plugins/add-ons for the core code I'm writing in the main project. attempted illustration: Workspace - a GIT-based project - submodule - submodule - submodule Again, I might just need clarification.
(In reply to comment #18) It's exactly your case I was thinking of. How common this is I'm not sure, but it seems we have at least one potential user.
Actually, that's 773 potential users for symfony2, according to the forks on GitHub. Another 9 potential users for PartKeepr, as well as doctrine2 with 212 forks. That's only a few projects I definitely know that they're using submodules, and there are other huge projects. So this is really a showstopper for many many projects.
(In reply to comment #19) > (In reply to comment #18) > > It's exactly your case I was thinking of. How common this is I'm not sure, but > it seems we have at least one potential user. The SilverStripe CMS uses this structure I've described, and all their code base has moved to github, so you can probably add a few hundred more to that list of potential users. :)
(In reply to comment #19) > (In reply to comment #18) > > It's exactly your case I was thinking of. How common this is I'm not sure, but > it seems we have at least one potential user. The project I am working on is also waiting for this feature. In my working group we have a main project with several plugins like Jeremy describes is his comment (comment #18). so add another 15 users.
The 20 or so Virgo and Gemini Web git repos use submodules too. That's quite a few users.
Submodules within projects are also used by the TYPO3 Project.
Submodules are indeed a very common way of structuring bigger GIT projects. I see and use them in allmost every project, so the lack of support forces me to bypass Eclipses GIT support entirely and manage the repositories with the command line/a sepearate GIT GUI, which is extremely annoying. I would consider submodules a very high priority.
I have begin working on adding support for certain submodule commands. I have pushed a change which currently supports submodule init, status, sync, and update. http://egit.eclipse.org/r/#change,4279 These could be used by the EGit clone wizard to initialize and update submodules after the clone finishes.
Is there a way this feature could be funded by those needing it to push it further up the priority list / get it out sooner? If so, can you provide an amount needed , and a means to pay that amount? The lack of this feature in EGit is what makes myself, and very likely others, stick to using SVN (Subversive, subclipse). Would others be interested in giving some incentive to this development?
It's on our roadmap for the next release, there's a gerrit change being worked on.
(In reply to comment #30) > It's on our roadmap for the next release, there's a gerrit change being worked > on. Ok, thanks for the update. In the mean time I'll exercise the lost art of patience.
(In reply to comment #29) > Is there a way this feature could be funded by those needing it to push it > further up the priority list / get it out sooner? If so, can you provide an > amount needed , and a means to pay that amount? > > The lack of this feature in EGit is what makes myself, and very likely others, > stick to using SVN (Subversive, subclipse). > > > Would others be interested in giving some incentive to this development? Hey Jeremy. While the lack of submodule support definitely makes using GIT less convenient, you can certainly still use GIT for your projects. Just use the command line or another GIT GUI to manage your repository. Not as nice as having it integrated, but certainly beats keeping to use SVN! ------ But: Great that it the importance of this was recognized. Can't wait for the submodule support to arrive.
(In reply to comment #32) > While the lack of submodule support definitely makes using GIT less convenient, > you can certainly still use GIT for your projects. > > Just use the command line or another GIT GUI to manage your repository. > > Not as nice as having it integrated, but certainly beats keeping to use SVN! My thought exactly. For instance, Virgo developers moved from svn to git 3 years ago and have never looked back in spite of all the Virgo repositories having a submodule and therefore not being fully supported by egit. Thankfully, there are excellent GUI apps available (such as SourceTree for Mac OS) which makes egit just a "nice to have".
(In reply to comment #30) > It's on our roadmap for the next release, there's a gerrit change being worked > on. Can you clarify what is meant by "next release?" 1.2, or later?
The next release will be the Indigo SR2 scheduled for February 24th 2012
This landed in master as 92c6f2f97bb478ac0d4731cacafaef52ac0d08d7 Waiting to close the bug until we have 1.3 bugzilla milestones.
Fixed in master.
Filed bug 367955 to hide the node if no sub-modules are present (it pollutes my view).
