I didn't really understand the first part. Isn't a monorepo how you get atomicity across sub-projects? If that was a problem for kubernetes, wouldn't a single c

I didn't really understand the first part. Isn't a monorepo how you get atomicity across sub-projects? If that was a problem for kubernetes, wouldn't a single commit that affected multiple repositories have the same issue? The merge issues seem like they would be solved by your code-hosting platform. (GitLab has Code Owners and Merge Trains and I imagine GitHub has something similar) To me, these features are something you'd implement in your centralized tool rather than git which has to support a decentralized workflow. Perhaps someone clever could think up a decentralized authorization system for git, but is it worth it when almost every project has a centralized source-of-truth repo?