> Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo much more expensive.

You might be happy to know Microsoft created a Virtual File System for Git[1] [2] so you do not have to have every file checked out in your working directory. Microsoft uses Git in a monorepo (for Windows, and it's 2.5 million files/300GB[2])

1. https://github.com/Microsoft/VFSForGit

2. https://vfsforgit.org/

This paper has details and history regarding Perforce and Piper: https://ai.google/research/pubs/pub45424

They used to use Perforce and then actually outgrew it (!), implementing an initially backwards-compatible backend called Piper.

(It may still be backwards-compatible, but it's been years since they turned off the last real Perforce and I haven't worked there for years myself. So it may have diverged.)

I used a git wrapper for google3 repo. It wasn't great. There are a number of semantic differences between piper/perforce and git that made it awkward. Especially code review- git doesn't handle code review well (I still find this to be an issue with github and other sites that have code review). but it was not an officially supported solution and I believe the replacement for it is based on another DVCS, Mercurial, for some silly software engineering reasons I don't like.

I used the git wrapper for a few days until I hit a day-ending `git gc`. That's when I knew git was terrible.

Afaik it's a custom system with download-and-cache-on-demand.

Note that there's nothing forbidding you from writing a virtual git filesystem that fetches objects from some centralized repo as files are open()ed. Git on cloud steroids.

Microsoft actually had done it and pushed the whole Windows repo into git.

https://github.com/Microsoft/VFSForGit

AFAIK they used perforce in the past and then built their own later.

FWIW, there is [used to be?] a git interface for the centralized monorepo. Really handy for managing multiple dev braches at the same time.

Vfsforgit let's you do that