[mindjiver]

I introduced git at $DAY_JOB roughly 2 years ago and based it on submodules. We use the submodule subscription feature of Gerrit to lessen the pain [1]. So submodules are not that bad but I really believe they are trying to solve a problem better solved by a dependency management system (maven and similar) instead.

So even subtree might be "easier" you should really try to solve your dependency problem using a resolver instead of your version control system.

[1] https://gerrit-review.googlesource.com/Documentation/user-su...

[durdn]

Oh I totally agree! If you can it makes sense to manage dependencies with tools that have been refined for years for the task like maven, gems, pip, npm, etc... I had this exact discussion with a colleague at Atlassian while writing about git submodule. Using git submodule or subtree might make sense if your environment is not homogenous, for example if you need to mix different languages and keep everything consistent. Even then you can use broader focus package managers like dpkg, rpm, apt, etc.

In any case I like the feel of git subtree as I have written in the post.

[mindjiver]

And I agree to this as well. :)

Our setup is quite special and in that case Gerrit/submodule subscription sort of works. But in hindisght we should have also tried to migrate to some generic packaging system. The reason for going with submodules was that we have ~1000 devs and most of their time they spend in their specific part of the code base. So we created submodules for these discrete parts so they wouldn't be "bothered" by changes to parts of the code base they don't normally access. Also we thought there wasn't so many cross-dependencies between the repos, but this turned out to be false.

We have now started to look at subtree for another product but I hope we can go directly to some packaging/dependency tool instead.