Hello.

I wanted to ask a question: what do you think about "mono-repos", aka: one repo for a bunch of projects.
One of the alternatives, which seems to me the more common solution, is to have one repo per project (say, "project-repo").
And the other alternative, which is also quite common, is to have projects divided into sub-projects: repos which depends on other repos, this mostly happens within big projects (say, "split-repo"?).

Personally, I've worked with mono-repos at work. It ended that, because of some peoples lack of skill, mono-repo was split, with repos depending on other repos (split-repo, since our codes had to work together anyway, and even shared code I wrote as libraries). Well, it was not really a sub-project division, but rather a per-dev division, since the unskilled one kept all his projects into a single repo (but at least could not pollute other's repos...).

I have also contributed to "project-repos", and am still contributing to some "split-repos", which are kind of "encouraged" by git's submodule (shitty) system.

My personal preference clearly goes to mono-repo, because it makes things easy as a dev: I have code I share between my projects. I put it in a subdirectory, each project have own directory. They even usually have their own branches (since I use git), that, when they have a changeset ready, gets rebased (so that I can keep a sane history) and then merged into master.
This makes things pretty easy from both my side (which I consider most important one, since I'm the one working on it) and on user's side which have to bother about less dependencies.
But, this approach also have disadvantages:
* it makes it hard to point others at a specific project, since everything is in the same repo,
* if a project grows too much, it can become quite heavy, which can become a problem depending on connnection,
* history is "polluted", as in, it will not only be the history of the single part you're interested in. I try to workaround that by using prefix in commits' title, and with git it can be solved by specifying the directory you want history of, but that's still not easy/practical,
* it requires discipline, in order to keep things organized. In my case, I forbid myself to touch multiple project's source-code in a single commit. Note that I don't consider the build system as code, to the contrary, I think it makes a lot of sense to have build system considered a project in it's own.

The "project-repo" approach, which is probably the most common one, requires less discipline, but require more user's intervention, since it is then required to clone all required repositories.

Both of those approaches have a big issue, though. If the project have some sub-parts with heavy files, like a game, there are technical issues when you try to clone or update the repo: bandwidth requirements, even if you don't intend to work on graphical, audio, or gameplay parts (usually called assets, but a recent discussion made me think it's a bad idea to call those assets, because that implies that the engine is worth nothing. Programmers are worth nothing...).
This problems is solved by the "split-repo" approach, but this approach usually also introduces difficulties when someone tries to work with the whole project.

So, which approach do you use?
Why?
In all situations?