True, that is one those interactions between users that I mentioned. But the amount of people having the code checked out and poking around its history is only

True, that is one those interactions between users that I mentioned. But the amount of people having the code checked out and poking around its history is only limited by capacity to clone the repository. All other operations are just local. Having hundreds of committers merging into one branch is problematic. Perhaps splitting the repository into smaller parts does have its advantages. Monorepos often have the architectural split of the software while throwing away the advantages of the split at the vcs level. But there is also other large software, developed by hundreds of people, that cannot meaningfully split into separate git repositories without messing about versioning and releasing. The Linux kernel is such a system. They use a loose network of repositories -- mostly a hierarchy -- to pre-aggregate merges. Git is well equipped to handle different approaches -- separation of mechanism and policy. I am looking forward to learn how a central but cloud-native VCS will improve on that.