I'm in the opposite situation, poly-repo hell. Our team produces 4 libraries. The code for them along with test apps is spread across 7 repos. So when I want t

I'm in the opposite situation, poly-repo hell. Our team produces 4 libraries. The code for them along with test apps is spread across 7 repos. So when I want to make a core change (like updating the version of Gradle we use) it results in 7 different PRs that have to go in at the same time, and that everyone has to fetch in sync. It's pretty rare that a change only requires a single PR because of this. Releases are a mess. To do a release we tag the latest commit in each of the repos with the same release number and use Jenkins to pull that tag from each repo and put it all together. But that's just like a suggestion, and it's not uncommon for a release to be based off of master. Good luck doing the forensics to figure out the state of everything for a release. The best part is that each repo needs to be in a specific folder on disk because some of them look for the others via hard-coded paths. There is one repo that needs to be separate, because it's public. But I've been pushing hard to get most of the repos pushed together into a single one just to add some sanity to my PRs.