0

I'm creating a monorepo that will include 2 current separate repositories. Let's just call then repo1 & repo2

However, I'm not 100% sure how to preserve the git histories of both correctly.

Both will have some similar branch names that I'm worried might have some impact in merging both successfully without conflicts? If I can only get the git history for a single branch on each repo, it's not the end of the world.

Both of the git repositories are still in progress, so, I am also not sure on how to merge in any future changes after I have already merged the current state of each repo into the monorepo (I'm not too worried about if it will be bit of a headache, but if it is a relatively simple solution then I'm all ears!)

I am aiming to have the following folder structure

monorepo
 ┣ packages
 ┃ ┣ repo1
 ┃ ┣ repo2
 ┗ package.json

I've done a little research and found I could do the following...

git remote add repo1 *git URL of repo1*
git fetch repo1
git merge repo1/main --allow-unrelated-histories

However this has 2 issues

  1. It merges into the root of the folder, so there is a package.json conflict, and I want to merge it into the packages/repo1 directory.
  2. It's only for a specific branch
    • Preferably it would be the entire git history, but again, I could live with this if getting the entire git history is a lot more complicated.
mcclosa
  • 943
  • 7
  • 29
  • 59
  • https://stackoverflow.com/a/1426163/7976758 – phd Oct 21 '22 at 13:22
  • Note that the history, in any repository, consists of the commits in the repository. Each commit stores a full snapshot of all files. So you can't really combine two repositories without "altering history". Git's submodules work around this by not actually *containing* the submodule repositories: they simply *refer to* specific commits in the submodule repositories, which are cloned separately. – torek Oct 22 '22 at 05:11
  • Branch names, if any, in the repository are not relevant here, with one exception: to *find* the commits in the repository, you need *some kind of names*. Tag names and other names will serve, but you'll generally find branch names in repositories as the way to locate the latest commits. So the names matter because (and exactly to the extent with which) you use them to locate the *commits* in the repository. Submodules sidestep this as well because the superproject's gitlinks record raw hash IDs, not names. – torek Oct 22 '22 at 05:13

0 Answers0