4 ms·

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 c

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.

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.