And when your CI fails, it blames to a specific commit, rather than "the commit that triggered it, plus any commit in a dependency repo around the same time." And if you need to maintain old release branches, each one is a single branch, and your tooling doesn't need to know anything special about what branches of other repos to check out. And `git bisect` works.

All of these things are possible without a monorepo, by using higher-level tooling to manage the relationship between repos. It could be `git submodules`, or Repo, or whatever. But all of those things have their own downsides.

git submodules tracks the version of the sub repos.

So if you organize that your releases are a master repo with all needed repos as sub-modules, your sub-repo version tracking is already done fr you.

All that while still allowing sub-repo to move forward faster than other repos. With a mono-repo, you can only allow some sub-system to go forward faster than others by making them live permanently in separate branches.

Basically, in monorepo you have to use branches to do what separate repo do normally for free.

(Then there is the issue that with a monorepo, any screw up screws everybody. You're all on the same boat, all the time.)

Yeah, we have set up a "parent" repo with git submodules for all the individual repos. But it was an afterthought and our workflow has not really caught up to the new possibilities.