Why Google didn't use Git

Replacing Git is in the news, so here’s a story from my time on Google’s source tools team 10 years ago.

The #1 question: why does Google use an awful Perforce clone for the monorepo instead of Git?

I met people across half the planet to find out. It’s not what you think!

The obvious technical answer is Git can’t handle it.

Google’s monorepo is massive and you’d have to clone the whole thing to every workstation, which could take a day or more and require terabytes of storage per desktop.

Access control is another. Some parts of the tree (though less than you’d expect) are trade secrets and you don’t want all engineers to be able to see it.

And the history is mostly noise. Tons of daily commits came from automation; Google’s infra-as-code lived in the same monorepo. Nobody needs all of that in their local history just to run git log.

These were all challenges but they weren’t the main reason. The main reason was personality conflicts.

You might think this would be a slam dunk. Google had its own Git server (called Git-on-Borg) managed by a dedicated team, and some developers on that team also had commit access to the official upstream Git open source project. It was the opposite.

It’s hard to believe now, given recent actions (looking at you, Android), but at the time Google was so idealistically committed to open source that people reacted with hostility if you even dared to suggest Google use its influence to push massive monorepo extensions into Git.

Instead, engineers on the source tools team were told to do months or years of engineering work on extensions, submit them to the Git project, and let the invisible hand of the open source community decide if they were fit to be included in Git. Only then would the Git-on-Borg team consider implementing them.

This was obviously insane, so the team just dropped it and focused on their Perforce clone. They considered Mercurial, which would have been much easier to extend thanks to Python duck typing, but it didn’t have Git’s name-brand familiarity and so was deemed not worth the churn.

Meanwhile, goddamn MICROSOFT was hard at work shipping massive monorepo Git extensions without a care in the world: VFS for Git (née GVFS) to virtualize the Windows repo, then Scalar and their own fork of Git, with pieces like the commit-graph, sparse-checkout and partial clone work making their way upstream.

Meanwhile Chrome and Android, stuck on Git because they had to share code with the world, spent 15+ years struggling to hold their massive codebase together with bubblegum and tape. All so nobody had to suggest Google was throwing its weight around.

In the end, Git really doesn’t scale. When Anthropic built Scion to replace it, the prior art they cited was Google’s shitty Perforce clone, Piper.

The Git-on-Borg team was right all along, albeit accidentally.

Want to argue about this? Let’s discuss it on my X cross-post.