It seems that either git
GUIs that I've tried are flawed in their submodules support, or git
itself doesn't handle submodules properly to begin with. When I do "reset to this commit" in the main repo, the subrepos are not updated so the project becomes broken. In Mercurial there's a special file that tracks the relation between each main repo commit and corresponding state of the subrepos. And reverting to older commits works as expected there, with subrepos always staying in sync. Does git not support that?
Asked
Active
Viewed 25 times
1

Violet Giraffe
- 32,368
- 48
- 194
- 335
-
1Just call "git submodule update" after resetting – mguijarr Jul 19 '15 at 20:40
-
@mguijarr: Thanks, but doesn't seem to help. The project can't be compiled after reset to older commit, and I never commit anything that doesn't compile. `submodule update` affected one subrepo, but not the other. – Violet Giraffe Jul 19 '15 at 20:44
-
You never commit anything that doesn't compile... Not a great idea IMO, usually I prefer to commit early to keep track of all changes. I am sorry I can't help you more, I guess your problem is not linked with git because the submodule update should have done the trick. Try a "make clean" ;) – mguijarr Jul 19 '15 at 20:55
-
@mguijarr: I also prefer to commit often and in small blocks, so I have to think my changes through so that they still at least compile, if not work. And it's not a build problem. One of the subrepos was not affected by `submodule update`. I reset that repo manually and everything builds now. I just wish they made Mercurial the default VCS for github (and called it differently, obviously :) ). It's so much better than git in so many ways. – Violet Giraffe Jul 19 '15 at 20:57
1 Answers
1
One of the subrepos was not affected by submodule update. I reset that repo manually and everything builds now.
That means the subrepo gitlink (special entry in the index)wasn't properly recorded (added, committed and pushed) in the parent repo.
The parent repo was referencing an older SHA1 for that submodule, and the git submodule update was setting that submodule to said older SHA1.
If you have reset the submodule manually, don't forget to go back to the parent repo, add, commit and push that modification (meaning the new SHA1 to which you just reset your submodule).
-
Could it have something to do with the fact that I've added the subrepo by simply editing .gitmodules? I did commit this subrepo to the main repo, though. – Violet Giraffe Jul 20 '15 at 09:29
-
1@VioletGiraffe yes, when it comes to submodule, it is best to use `git submodule` commands, like `git submodule add`, to add a submodule. – VonC Jul 20 '15 at 09:33
-