Google had to build an internal version control system as an alternative to git and perforce to support their monorepo.

Microsoft forked git and layered their own file system on top of it to support a centralized git workflow so that they could have a monorepo.

Your logic is circular.

    No one should work on monorepos because...
    monorepos are bad because...
    git can't easily handle them and we shouldn't fix that because...
    No one should work on monorepos...

Clearly there are reasons people like monorepos and it makes sense to update git to support the workflow.

That isn't circular. The conclusion should be that git, a decentralized vcs, should not take on changes to make it a centralized vcs.

If you think that git needs to be "fixed" or "updated" to support a centralized vcs server to do partial updates over the network, then I think you've missed the point of git.

Having had used both, Google's implementation is IMO the superior version of monorepo. Really, Google's Engineering Systems are just better than anything that I have ever used anywhere else.

This is exactly as I'd expect.

If you want a centralized, trunk-based version control, don't use git.

It's funny how each company decides to solve these problems.

Google called in the computer scientists and designed a better centralized vcs for their purposes. Good on them. It'd be great if they open sourced it. So typical of Google to invent their own thing and keep it private.

Microsoft took the most popular vcs (git), and inserted a shim layer to make it compatible with their use case. How expected that Microsoft would build a compatibility shim that attempts to hide complexity from the end user.

Meanwhile, Linux and Git are plugging along just fine, in their own separate repos, even though many people work on both projects.

Google did not design a VCS from scratch, they adopted Perforce and started replacing its backend as they hit scaling limits. They eventually added some kind of copy-on-write FUSE layer that looks like your workspace contains the entire monorepo, which was pretty cool.

It would be hard to open source if its dependencies only exist on Borg. I think that was a problem with Blaze (now Bazel).

> So typical of Google to invent their own thing and keep it private.

Yeah like their build system... Bazel, that's completely closed source.

Sparse index has literally nothing to do with VFS for Git. The sparse index features are in microsoft/git because it's a convenient, deployed-at-scale test-bed before upstreaming into git/git.