5 ms·

The upside of having a monorepo with just one version of everything is that all the code is compatible with each other and easy to understand across projects.

The upside of having a monorepo with just one version of everything is that all the code is compatible with each other and easy to understand across projects. Among other things it prevents diamond-dependency problem and other dependency issues. Google binaries are already regularly hitting the upper size limits for linker. If you needed to link 5 versions of each library it would greatly exacerbate the problem. Having a monorepo also greatly benefits maintaining security. You only need to fix a security issue in the trunk, and the fix will automatically be applied in every binary that uses your library upon its next rollout. > all to optimize consumer behavior to boost ad revenue. I've been working for Google for more than 12 years and never ever have I thought about optimizing ad revenue. Not just that, but I also never heard about this consideration in any meeting that I attended over the years. > Did I mention the report was commissioned, in part, by Google? (End of Aside.) I don't see how this in any way invalidates the conclusion. It's not like this report was commissioned for marketing purposes. > note git is not allowed at Google This is very misleading. All Google open source projects, including Chromium, AOSP and all of github.com/google use git. What is not supported is a git frontend to the internal VCS. This is mostly due to the fact that support of any additional tool required staffing, so only a limited number of configurations/tools can be supported.

disgruntledphd2 5y ago
> What is not supported is a git frontend to the internal VCS. This is mostly due to the fact that support of any additional tool required staffing, so only a limited number of configurations/tools can be supported. It's super weird to me that Google wouldn't staff this. Given how much of the external world uses git, I would have thought that keeping new hires productive would have made this staffing requirement a no-brainer. But what do I know, I don't work for Google. I'd be super interested if anyone knows why this is the case, though.
- eterevsky 5y ago
  I'm also slightly disappointed by the decision not to support git, but honestly it doesn't really affect productivity. You have two interfaces to the version control system: one native, that evolved from Perforce, and the second one based on Mercurial, which is pretty similar to what can be done with git. At some point there was a decision to be made whether to support Mercurial or git, because they have very similar feature sets. I don't quite know why they made the choice they made. To clarify, all of this only affects the client side of the VCS. It is not really possible to use either git or Mercurial for repository storage without some major trickery.
  - disgruntledphd2 5y ago
    OK, that makes a lot more sense. So the One True Repo is Perforce (it's hilarious to me that Google use Perforce[0]), and there are shims to use it as if it was Mercurial or Git, but the Git one got killed and hasn't been replaced. Thanks so much for the extra information! [0] I have no real opinion on Perforce, but I always thought that the reason game studios used it was to deal with binary assets, and I'm surprised that Google would have lots of those.
    - eterevsky 5y ago
      It's not Perforce. It was Perforce 20 years ago. Since then it was completely rewritten, while preserving some backwards compatibility. Here's an article that I've found: https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
  - summerlight 5y ago
    > I don't quite know why they made the choice they made. It was mostly technical one. Piper itself is a distributed file system which has significant incompatibility with git's internal model and git didn't provide a good extension model to hack with. So to provide deep integration, forking was the only viable option at the moment. Perhaps the equation might be different now since MS did some contribution for their own use and git maintainers have become less reluctant to accept features for monorepo use cases, IIRC. Still, it's harder to retrofit the existing distributed file system into the core git object model than to develop a new one designed with that in mind.
- gipp 5y ago
  There was at one point a git interface. It was extremely cumbersome to use compared to the perforce/mercurial ones and was eventually deprecated. I can't speak to how much of that is staffing limitations versus underlying technical reasons for poor compatibility. At any rate, it's extremely simple to move to Mercurial from the git world, particularly with trunk-based development.

disgruntledphd2 5y ago

> What is not supported is a git frontend to the internal VCS. This is mostly due to the fact that support of any additional tool required staffing, so only a limited number of configurations/tools can be supported. It's super weird to me that Google wouldn't staff this. Given how much of the external world uses git, I would have thought that keeping new hires productive would have made this staffing requirement a no-brainer. But what do I know, I don't work for Google. I'd be super interested if anyone knows why this is the case, though.

eterevsky 5y ago
I'm also slightly disappointed by the decision not to support git, but honestly it doesn't really affect productivity. You have two interfaces to the version control system: one native, that evolved from Perforce, and the second one based on Mercurial, which is pretty similar to what can be done with git. At some point there was a decision to be made whether to support Mercurial or git, because they have very similar feature sets. I don't quite know why they made the choice they made. To clarify, all of this only affects the client side of the VCS. It is not really possible to use either git or Mercurial for repository storage without some major trickery.
- disgruntledphd2 5y ago
  OK, that makes a lot more sense. So the One True Repo is Perforce (it's hilarious to me that Google use Perforce[0]), and there are shims to use it as if it was Mercurial or Git, but the Git one got killed and hasn't been replaced. Thanks so much for the extra information! [0] I have no real opinion on Perforce, but I always thought that the reason game studios used it was to deal with binary assets, and I'm surprised that Google would have lots of those.
  - eterevsky 5y ago
    It's not Perforce. It was Perforce 20 years ago. Since then it was completely rewritten, while preserving some backwards compatibility. Here's an article that I've found: https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
- summerlight 5y ago
  > I don't quite know why they made the choice they made. It was mostly technical one. Piper itself is a distributed file system which has significant incompatibility with git's internal model and git didn't provide a good extension model to hack with. So to provide deep integration, forking was the only viable option at the moment. Perhaps the equation might be different now since MS did some contribution for their own use and git maintainers have become less reluctant to accept features for monorepo use cases, IIRC. Still, it's harder to retrofit the existing distributed file system into the core git object model than to develop a new one designed with that in mind.
gipp 5y ago
There was at one point a git interface. It was extremely cumbersome to use compared to the perforce/mercurial ones and was eventually deprecated. I can't speak to how much of that is staffing limitations versus underlying technical reasons for poor compatibility. At any rate, it's extremely simple to move to Mercurial from the git world, particularly with trunk-based development.