It's funny that you mention this as if monorepos of course require custom tooling. Google started with off-the-shelf Perforce and that was fine for many years, long after their repo became truly huge. Only when it became monstrously huge did they need custom tools and even then they basically just re-implemented Perforce instead of adopting git concepts. You, too, can just use Perforce. It's even free for up to five users. You won't outgrow its limits until you get about a million engineer-years under your belt.
The reason git doesn't have partial repo cloning is because it was written by people without regard to past experience of software development organizations. It is suited to the radically decentralized group of Linux maintainers. It is likely that your organization much more closely resembles Google or Facebook than Linux. Perforce has had partial checkout since ~always, because that's a pretty obvious requirement when you stop and think about what software development companies do all day.
It’s somewhat mind boggling that no one has made a better Perforce. It has numerous issues and warts. But it’s much closer to what the majority of projects need that Git imho. And for bonus points I can teach an artist/designer how to safely and correctly use Perforce in about 10 minutes.
I’ve been using Git/Hg for years and I still run into the occasional Gitastrophe where I have to Google how to unbreak myself.
git have added recently sparse checkout and there is also Virtual File System for Git from Microsoft.
From my experience git/vcs is not an issue for monorepo. Build, test, automation, deployments, CI/CD are way harder. You will end with a bunch of shell scripts, make files, grunt and a combination of ugly hacks. If you are smart you will adopt something like bazel and have a dedicated tooling team. If you see everything as nail, you will split monorepo into an unmaintainable mess of small repos that slowly rot away.
I have had the exact opposite experience. Long term maintenance in a monorepo is much easier because all developers have visibility into changes. Tooling isn’t really all that complex (at least to me and I’m not a devops engineer either). It’s way more complex to me to have multiple repositories. I’d rather have hundreds of directories that follow uniformity rather than hundreds of git repositories that may not
For me the complexity comes when you have many isolated projects sharing code. With a mono-repo that shared code is immediately consumed by all isolated projects, most of which the developer is not actively looking at to look for breakages.
This means that every single commit every single test suite has to be run across the whole organization. For a small startup that's probably fine, but for a larger organization that adds a ton of issues and extra time. If your change to a shared project breaks another project that you may not be familiar with you end up not only with a delayed context switch (since you don't know about it until the CI has finished running all tests across the whole org), but now you have to figure out how to address it before someone else changes code in that shared project which causes a merge conflict.
Compare that to a split-repo setup where projects are sharing code indirectly (via package management systems). When you change code other projects will only consume the new code when they actually upgrade their packages, and usually a developer that is familiar with the code base will actively hit that breakage in real time.
Granted, this has its own trade offs such as all your systems may be running different versions of shared code, and the delay in breakage detection can cause some back and forth in breakage between isolated projects.
This to me sounds like a break down of documentation and software architecture patterns, not so much a flaw of a monorepo. I’d rather it come up at that stage anyway even if it’s a pain, because it will help re-enforce better patterns and documentation as people feel these pain points. Shared libraries should have a code owner that is responsive for this if it’s not agreed that it’s straightforward enough to work on as an individual dev no?
That why I mentioned Bazel, once monorepo reach certain size you need to invest in right tooling. What people do instead is splitting into multi-repo and keep using the same tooling. By splitting repo you exchange easy problem of scaling tooling for very hard multi-repo/micro-service/coordination. IMO, the biggest problem with splitting repo is Conway Law, once split you change important dynamics of product development.
The reason git doesn't have partial repo cloning is because it was written by people without regard to past experience of software development organizations. It is suited to the radically decentralized group of Linux maintainers. It is likely that your organization much more closely resembles Google or Facebook than Linux. Perforce has had partial checkout since ~always, because that's a pretty obvious requirement when you stop and think about what software development companies do all day.