Le 13/02/2018 à 14:06, Robert P. J. Day a écrit : > looking for general opinions ... i am (frighteningly :-) teaching a > git course later this week, and one of the topics on the list is git > submodules, which was specifically requested by the client as their > idea of how to start incorporating child repos in new projects. > > however, given the number of articles written about the drawbacks > with submodules, i wanted to throw in a section about "git subtree" as > well, even though (as discussed earlier) there is some minor dispute > as to whether "git subtree" is part of "core" git, but i'm not going > to let that stop me. I've dealt with a large number of submodules and subtrees in the last years so here are my 2 cents. The first question to ask is the most important one: Do the repos really need to be split at all. In a previous life, we started with one repo per "small projects", each containing a couple of binaries or libs. Everything was put together through submodules. After way too long to admit, we realized that it was just not worth it. We had to deal with so many corner cases in CI and other things for a no real gain. The reality is git works perfectly with bigger projects and smart enough that people working on two different "subprojects" don't create any conflict. So we started merging a lot of it back into the main repo and that was it. I see some advantages submodules have other subtrees: - It's slightly easier to in a subproject when using submodule than with subtree (at least for git newcomers). Once you made sure your submodule is on a branch, you just go into it and work in a standard git. When using subtree, you have to know you're in a subtree and to your subtree push/pull to resync with someone working directly in the subproject. At the time conflict in subtrees were sometimes a bit weird and created history full of merge. - submodules are great when working with huge subrepo. We have a repository than had among its submodule: linux, gcc, gdb, glibc. This means a real lot of code/files and commits. Subtree would work but you'd endup with a humongous repo and as expected everything is slowed down. - submodules work well when you are moving between versions and branches of a subproject. Let me clarify with an example: We had a repo that had ffmpeg as a submodule with a large patch series from us. We would regularly create a new branch in the subrepo with all our patches on top of a new ffmpeg upstream release. And simply point the top project to this SHA1. And it worked great. I wouldn't risk doing that kind of things with subtree. I may be wrong here (I haven't tried it to be honest) the the push/pull approach doesn't seem to fit the idea of moving from a SHA1 to a seemingly unrelated one. Now that I'm working with reasonable repo sizes again, and linear history, I mostly stick with subtrees. Nicolas
