Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file.
What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready").
Not to say Linux should change their ways, just that I wouldn't adopt them as part of a company.
I think a big chunk of "why is the kernel's git workflow the way it is" is just "it's a formalized and tooled-up equivalent of the preexisting organizational structure where everybody was emailing patches, submaintainers had kernel source trees on their local machines that they were in charge of, etc". That said, one area I suspect the 'branches in a common repo' model will have trouble is access control. With the kernel's approach I can set up a tree for the Foo subsystem without needing to have any kind of privileged access to the 'official' kernel tree: whoever I send Foo pull requests to chooses to accept them, or not, case by case. I don't get to make unreviewed changes to other bits of code. (Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?)
You can do kernel development with a "we give commit access out fairly freely" model, of course (I think some of the BSDs are like that, again as historical accident of the cvs style tooling they used to use); but Linux hasn't historically been socially organised that way, and changing tools is easier than changing organisational structure.
But then I realized that the advantage of multiple repos is that it is decentralized: anyone can start their own fork, and collaboration works similar to the official forks, and you don’t need any centralized administration.
Having everyone share a single giant monorepo sounds like you’ll need a lot of people to support the infrastructure. Microsoft can do that. Can the Linux community?
With a huge monorepo, you can easily archive everyones contributions. That’s probably important for Microsoft. It’s not important for Linus — he only cares about the stuff he merges.
Finally, multiple repos allow people to work on stuff privately, and only contribute back to the public when they are ready.
Sometimes a monotree is the only way. If your business model revolves around an open source core with some proprietary add-ons for paying customers, it's often not possible to merge those codebases into a single repo.
Not sure why people are downvoting you. Just because Microsoft decided to give an already-in-use name to an internal project doesn't mean that the original project no longer exists. https://wiki.gnome.org/Projects/gvfs
What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready").
Not to say Linux should change their ways, just that I wouldn't adopt them as part of a company.