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).

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.