[trollied]

> With a monorepo, projects can be organized and grouped together in whatever way you find to be most logically consistent, and not just because your version control system forces you to organize things in a particular way. Using a single repo also reduces overhead from managing dependencies.

I don't actually understand this. You can do this with git submodules. It's just a directory structure. Can somebody please explain? If the problem is committing to multiple things at the same time for a point-in-time release, then the answer is tags. Rather than terabytes of git history for a gigantic organisation that has many unrelated projects.

A good example for you: Google releases the Google Ad Manager API externally periodically, with dated releases. How does having that in a huge monorepo make sense?

[nickdandakis]

Have you used git submodules before? I've only used them once and vowed to never use them again.

It's effectively just a pointer to a hash, and ends up being useless for versioning + a really nice footgun for tracking upstream updates.

The monorepo vs manyrepo tradeoff boils down to this:

Do you want more complicated build + deploy tooling or do you want more complicated dependency management?

If the former, pick monorepo. If the latter, pick manyrepo.

[perrygeo]

This is the best summary of the topic I've read. Having used all three (submodules, monorepo, manyrepo) the only thing I can say with any certainty is - don't use submodules. The mono/manyrepo decision is not as clear cut but your description nails it.

Edit: submodules IS a viable solution for truly third-party repos over which you have no control and don't expect to ever edit.

[slavik81]

Have you ever tried contributing to Qt? I rather liked their use of submodules. https://github.com/qt/qt5