I'm in basically the same boat, microservices in multiple repos that I've waffled on merging into a single repo. Each time the lack of history preservation was a big non-starter.
It would be nice to be able to place the sub-repos into non-root locations. Much of my desire to switch to a monorepo was to refactor some of the code organization also.
Unfortunately, git with submodules is a far cry from a single, coherent repository. Tooling is practically out the window (integration with any IDE, for example), snapshotting becomes a nightmare, coordinating your different versions becomes a nightmare.
Git sumbodules are good[1] for referencing external dependencies with their own timeline who don't depend nor interact with your project or code. They are not a great fit when your submodules are intimately related to the code around them.
[1] arguable---I personally despise them, but let's assume they're good
3 comments
[ 2.5 ms ] story [ 14.8 ms ] threadIt would be nice to be able to place the sub-repos into non-root locations. Much of my desire to switch to a monorepo was to refactor some of the code organization also.
Unfortunately, git with submodules is a far cry from a single, coherent repository. Tooling is practically out the window (integration with any IDE, for example), snapshotting becomes a nightmare, coordinating your different versions becomes a nightmare.
Git sumbodules are good[1] for referencing external dependencies with their own timeline who don't depend nor interact with your project or code. They are not a great fit when your submodules are intimately related to the code around them.
[1] arguable---I personally despise them, but let's assume they're good
(disclaimer: I wrote the article)