It worked far better than you'd think. The ability to atomically change massive chunks of Google's code across projects was amazing. At some companies I worked at, if you wanted to make a breaking change in a common library, like say rename a method, it'd be a serious issue. You'd need to release a new version of your library, then you'd start migrating teams using that library one by one or cajoling them into it, and then, years later, you might be able to delete the old version. And you'd have to maintain it the whole time. At Google, you could just rename the method in the library and in every client of that library in the same single commit. It was magical! Almost all development at Google was done at HEAD in a single branch, and it was a beautiful thing. It's probably also why Bazel and Google's open source stuff are not great at versioning and backwards compatibility; it's not something they worry about internally.

I've worked with some Xooglers who were incapable of working on smaller repos without google's internal tools for this kind of thing. And I mean literally incapable of writing meaningful code or pushing to main.

Total anecdote and not worth much, but I've seen it enough times to make note of it.

There's no other way to run a firm this size without half of it being mired in dependency hell.

This is not the monorepo you are thinking of. And yes I've seen $M in developer time burned by people who didn't understand that.

it’s not a monorepo in the git sense of monorepo. git won’t scale that way.