I recommend using https://github.com/newren/git-filter-repo instead of filter-branch.
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
The mainstream version of this post is called subtree-merge and supported by recent Git versions ootb
How is this different from running git pull or git push to a remote?
huh good to know. I often just make and apply patches when I'm dealing with different histories. Doesn't always work though.
If the goal is to move all the commits of one repo into another repo, Git provides subtree merges:
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).