I introduced a submodule at my last job to hold common build code used across multiple repositories. I knew going in that some of our developers didn't really u

I introduced a submodule at my last job to hold common build code used across multiple repositories. I knew going in that some of our developers didn't really understand git, and were not interested in rectifying that. I won't say the submodule was a disaster, but I definitely paid for it with time spent sitting with people and helping them fix messes. I would do it again but only if I knew I could count on the team to make more than a token effort to understand what a submodule was and how it worked. I would not even consider adding multiple submodules unless I felt like everyone knew exactly how to use them. Another potential source of issues: the submodule remote URI is checked in as part of the .gitmodules file. If your CI system uses a different URI than your developers, you have to work around that. If you change where your source is hosted and you want to check out an old version, you have to figure that out too. That said, I think the most common reason is the same reason some people prefer monorepos in the first place: they perceive the monorepo as simpler, and adding submodules is not simpler. They want to know about and manage 1 repository clone. They want to commit, push, review, and build out of 1 repository. They want to search for stuff in 1 directory tree. They'd also like to do that with 1 tool, ideally 'git'. Nothing really offers that except monorepos.