They do not use an usual git repository. Companies using monorepos have tools to restrict people's access to parts of it, and filter log noise.
Or, in other words, it's not that insanely complicated, because they have tools that make it look a lot like multiple repositories. And the large companies using multiple repositories have tools that make them look just like those monoreps. And HN has all those interesting threads full of people saying why one is better than the other.
The feature I missed about Subversion was, if you could figure out how to treat your code like a proper tree, individual teams would check out one, maybe two directories, and only the leads and operational people ever had the whole thing.
I never entirely understood what it was in subversion's internals that prevented it from being used as a DCVS. We could figure out version numbers with branches and multiple repos. If not then, certainly now.
There's a space between subversion and Git that could be occupied with something that sheds the worst behaviors of each and makes something better.
Versions are a tree structure. The implementation may have required the next revision number to be n + 1, but the data structure does not necessarily have to do that. If myself and someone else push commits, they have to be rebased and renumbered anyway, right?
Or, in other words, it's not that insanely complicated, because they have tools that make it look a lot like multiple repositories. And the large companies using multiple repositories have tools that make them look just like those monoreps. And HN has all those interesting threads full of people saying why one is better than the other.