so for most of us the only reasonable path is to split into multiple repositories.
it is also easier to create tools that deal with many repositories.
than it is to create a tool that virtualizes a single large repo.
Well, because of the unbelievable amount of engineering work involved in trying to get Git to operate at such insane scale? To say nothing of the risk involved in the alternative. This project in particular could easily have been a catastrophe.
It can be hard to understand this as an individual engineer, but large tech companies are incredible engineering machines with vast, nearly infinite, capacity at their disposal. At this scale, all that matters is that the organization is moving towards the right goals. It doesn't matter what's in the way; all the implementation details that engineers worry about day-to-day are meaningless at this scale. The organization just paves over over any obstacles in pursuit of its goal.
In this case Microsoft decided that Git was the way to go for source control, that it's fundamentally a good fit for their needs. There was just implementation details in the way. So they just... did it. At their scale, this was not an incredible amount of work. It's just the cost of doing business.
They're running both source control systems in parallel, switching developers in blocks, and monitoring commit activity and feedback to watch for major issues. In the worst case, if GVFS failed or developers hated it, they could roll back to their old system.
Again, to my point above: there's a cost to doing this but it's negligible for very large organizations like Microsoft.
https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
100 urls? That's getting a bit annoying.
Not that I'd want to run it on such a mega-repository; it takes long enough running it on an average one with a decade of history.
https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
Android, Chromium, and Linux (among others, I'm sure) are different in that they use git for version control so they are in their own separate repos.
Why doesn't this make sense.
I personally think of a repo as of an index not a filesystem. You checkout what you need but there is one global constant state - which can eg be used for continuous integration tests