I'm sorry, people were doing what?
@remmy @0xabad1dea Piper is Google's internal clone/rewrite of Perforce using its own infrastructure. They have a single monorepo called google3 that stores almost all of the source code for the entire company's products. I don't know how many engineers that is nowadays, but certainly O(10,000s) all using one repo. To make any change you create a "changelist", kind of like a PR in Git terms. Changelists are assigned as a monotonically increasing quantity. So when the company would get close to some significant epoch like "changelist #100000000" a bunch of engineers would all run shell scripts creating hundreds of new changelists to get the nerd cred of being the one to create that one special changelist number.
................Why in *THE FUCK* would you *reimplement* *Perforce*?
@emc2 @remmy @0xabad1dea as I understand it, rewriting it was easier than changing the workflow of every engineer in the company and migrating all the infrastructure that had been built on top of it. TBF it did have some genuine quality of life improvements over the original Perforce ("client in the cloud" virtual filesystem etc)
Edited 16h ago
Migration from Perforce to git is pretty painless. I did several such migrations some time back. It's installing a plugin and then running the migration command.
It is certainly less pain than actual *using* Perforce for even a planck unit of time
@emc2 @remmy @0xabad1dea well, the maintainer of Git has been a Google employee since 2010 and they haven't been able to do that. So perhaps not as simple and painless as you might think
@emc2 @fraggle @remmy @0xabad1dea git would be a legitimately bad choice for what Google are doing - you can’t have everyone needing to pull every change anyone in Google made to get the one change they do care about in a subset of that. Also distributed version control makes no sense in a company where to my understanding it’s not permitted to have source checkouts on your local device.