4 ms·

Start working in a repo with submodules and you suddenly have to understand a lot more and can get into trouble with no idea how you did it.

relics443 9y ago
I'm comfortable with most advanced git stuff. I don't touch submodules.
- _pmf_ 9y ago
  > I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
  - buserror 9y ago
    I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
    - _pmf_ 9y ago
      Never heard of them (well, probably in passing); will look into is. Thanks!
  - yawaramin 9y ago
    Why isn't it feasible for C++ projects?
lilbobbytables 9y ago
Oh you can fuck right off with submodules!
- greasyjon1 9y ago
  ^^^ this comment is supposed to be humor, not douchebaggery, by the way. Easy on the downvotes.
xxpor 9y ago
I use submodules every day, never had a problem with them. What do people complain about when it comes to them? My mental model is basically that they're separate repos, and the main repo has a pointer to a commit in the submodule. Do your work that needs to be done for the submodule, push your changes, and then check out that new commit. Make a commit in the main repo to officially bump the submodule to that new commit. Done. The annoying part is when you do a pull on the main repo, you have to remember to run git submodule update --recursive.
- flatline 9y ago
  Right, it’s not that hard, but there are some gotchas. The most common problem I see is the local submodule being out of sync with the remote superproject. Pushes across submodules are not atomic. Accidentally working from a detached head then trying to switch to a long out of date branch can be an issue, as can keeping multiple submodules synced to the head on the same branch. Recursive submodules are, as you mentioned, even more fun.
  - AstralStorm 9y ago
    The same problem appears in any non monolithic project. In any SCM I know of. Git subrepo or subtree are some of a solution but not quite complete and easy to use. In some other scms (P4 and SVN, partly hg) the answer is don't do that, which had a whole lot of its own problems.
- chris_wot 9y ago
  Oh, so that's what you do!
  - xxpor 9y ago
    Heh, I probably made it sound more complicated than it really is. Just think of it as a pointer that needs to be manually updated.
- friend-monoid 9y ago
  Because you have the .gitmodules file, the .git/config file, the index, and .git/modules directory, each of which can get out of sync with the others. If, for example, you add a submodule with the wrong url, then want to change the url, then you instinctively change .gitmodules. But that won't work, and it won't even nearly work. If you add a submodule, then remove it, but not from all of those places, and try to add the submodule again (say, to a different path), then you also get wierd errors. If you add a submodule and want to move it to another directory then just no. Oh and also one time a colleague ran into problems because he had added the repo to the index directly - with git add .. Oh and let's talk about tracking submodule branches and how you can mess that up by entering the submodule directories and running commands...

relics443 9y ago

I'm comfortable with most advanced git stuff. I don't touch submodules.

_pmf_ 9y ago
> I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
- buserror 9y ago
  I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
  - _pmf_ 9y ago
    Never heard of them (well, probably in passing); will look into is. Thanks!
- yawaramin 9y ago
  Why isn't it feasible for C++ projects?

lilbobbytables 9y ago

Oh you can fuck right off with submodules!

greasyjon1 9y ago
^^^ this comment is supposed to be humor, not douchebaggery, by the way. Easy on the downvotes.

xxpor 9y ago

I use submodules every day, never had a problem with them. What do people complain about when it comes to them? My mental model is basically that they're separate repos, and the main repo has a pointer to a commit in the submodule. Do your work that needs to be done for the submodule, push your changes, and then check out that new commit. Make a commit in the main repo to officially bump the submodule to that new commit. Done. The annoying part is when you do a pull on the main repo, you have to remember to run git submodule update --recursive.

flatline 9y ago
Right, it’s not that hard, but there are some gotchas. The most common problem I see is the local submodule being out of sync with the remote superproject. Pushes across submodules are not atomic. Accidentally working from a detached head then trying to switch to a long out of date branch can be an issue, as can keeping multiple submodules synced to the head on the same branch. Recursive submodules are, as you mentioned, even more fun.
- AstralStorm 9y ago
  The same problem appears in any non monolithic project. In any SCM I know of. Git subrepo or subtree are some of a solution but not quite complete and easy to use. In some other scms (P4 and SVN, partly hg) the answer is don't do that, which had a whole lot of its own problems.
chris_wot 9y ago
Oh, so that's what you do!
- xxpor 9y ago
  Heh, I probably made it sound more complicated than it really is. Just think of it as a pointer that needs to be manually updated.
friend-monoid 9y ago
Because you have the .gitmodules file, the .git/config file, the index, and .git/modules directory, each of which can get out of sync with the others. If, for example, you add a submodule with the wrong url, then want to change the url, then you instinctively change .gitmodules. But that won't work, and it won't even nearly work. If you add a submodule, then remove it, but not from all of those places, and try to add the submodule again (say, to a different path), then you also get wierd errors. If you add a submodule and want to move it to another directory then just no. Oh and also one time a colleague ran into problems because he had added the repo to the index directly - with git add .. Oh and let's talk about tracking submodule branches and how you can mess that up by entering the submodule directories and running commands...