A monorepo misconception – atomic cross-project commits
In articles and discussions about monorepos, there's one frequently alleged key benefit: atomic commits across the whole tree let you make changes to both a library's implementation and the clients in a single commit. Once you're sure the commit from stage 1 won't be reverted, push N commits to switch each of the N clients to use the new interface. Depending on the risk profile of the change, you might even use these commits as a form of staged rollout, where you'll wait to see if the previous clients report any problems in production before sending the next batch of commits for code review. If anything goes wrong in stage 3, it would also have gone wrong when using atomic commits. With atomic commits the breakage in stage 3 is far more likely, since the new users will naturally use the old interface, and since the window between start of code review and committing will be wider. There might be a few cases where atomic commits across the whole repository are the right solution, but it has to be exceedingly rare. Are there organizations with a large monorepo where atomic cross-project commits are routinely used to change both the implementation and the clients?