For companies that started out making lots of small repositories that want to moev incrementally to a monorepo, this strategy can be useful because it sets up the smaller repo as a self-contained unit of the larger repo, preserving things like git commit history and git blames. After a subtree merge, further steps can more tightly integrate the code into the larger repository (i.e., so that it is no longer wholly contained in the subtree).
I merged two codebases (several thousand commits each) into a monorepo using a similar strategy. Instead of top level files in an api repo, and top level files in a web repo, we have packages/api and packages/web. It feels magical that I can open up a blame for a file in either package when most commits occurred in separate repos spanning back 5 years
Without reading everything it seems like you can change the paths and still keep the history (of both), while seeing both simultaneously, as opposed to switching branches, like it seems you are saying.
no, I am not talking about switching branches. I mean pushing to a remote repository. Git was designed to be decentralized such that you can push and pull from multiple machines in any flow you like. Most folks at engineering shops use git in a central model from my experience
https://docs.github.com/en/get-started/using-git/about-git-s...
For companies that started out making lots of small repositories that want to moev incrementally to a monorepo, this strategy can be useful because it sets up the smaller repo as a self-contained unit of the larger repo, preserving things like git commit history and git blames. After a subtree merge, further steps can more tightly integrate the code into the larger repository (i.e., so that it is no longer wholly contained in the subtree).