A quick and dirty way I usually combine private repositories is to use the --rebase option for git pull. I have written about such option already in a post about keeping git fork in sync with the upstream. Here's how to do it:

git remote add --fetch other ../other-repository
git pull --rebase other main

This is especially good if there are little to no conflicts to be resolved. Another advantage is that it puts commits from that other repository at the bottom of the history, so your recent work is in the same place, at least visually in a git log. The remote can also be safely removed now:

git remote remove other

The obvious disadvantage of combining repositories this way is that it rewrites git history. Even though the latest commits look unaffected, their hashes has changed. This means that using this method for anything other than local private repositories is discouraged. Consider it to simply be a fast unobtrusive alternative to your local work.

Preserving a chronological commit order

Combining two unrelated repositories into one while maintaining the commit history in a chronological order is something I tried to search up multiple times already, yet the solutions offered are usually these two:

  1. Merge on top and then cherry-pick commits
  2. Merge on top and then rebase interactively

However both solutions require a lot of manual work and are error prone. There are odiously some better or worse scripts that do this automatically and they can be quite effective, here's a summary of the link for the record:

git init
git remote add --fetch repoA ../repoA
git remote add --fetch repoB ../repoB
# The magic
git log --all --oneline --format="%at %H" | \
  sort | cut -c12- | xargs -I {} sh -c \
  'git format-patch -1 {} --stdout | git am --committer-date-is-author-date'

This had worked for me as well. Use with care as it too rewrites git history!