Merge two git repositiories, with separate roots and histories, into one-CodePudding

This is what I have

RepoA: root ➊ → ⋯ [History A] ⋯ → ➌
RepoB: root ➋ → ⋯ [History B] ⋯ → ➌

where the files (➌) in each repo are now identical, but the histories and roots are entirely unrelated.

This is what I want, but both Git and related queries I've been here and elsewhere seem to be going out of their way to avoid this!

RepoA:

branchA root ➊ → ⋯ [History A] ⋯ → ➌
                                     \
                                       ∙ → ➌
                                     /
branchB root ➋ → ⋯ [History B] ⋯ → ➌

merged together into RepoA, keeping the root and history of RepoB separate from that of RepoA, so that when I look at the history of any file, after the merger, it will show separate histories from each branch, and not mangle the two sets of histories together.

It's a mash-up of two separate code-bases. I have many projects like this, not just one or two. Some may eventually come to have many different lines of ancestry, rather than just two. Yet, GitHub seems to be specifically blocking this very situation!

CodePudding user response：

It's a mash-up of two separate code-bases. I have many projects like this, not just one or two.

Normally, each projects would be in its own repository.

But if not, assuming repoB has only one branch of interest (say main):

cd repoA
git switch main
git add repoB URL/repo/B
git fetch repoB
git merge --allow-unrelated-histories -s ours repoB/main

You can repeat that for others "repoB", but the end-result will be a giant repository whose entire codebase will be branches or tagged as "one".
That may, or may not be what you want/need.

CodePudding user response：

I don't think there is an answer to your query. As far as I'm aware, no git repository can have more than one root - ever! (And this may not have always been the case.)

"git init" will create a new repository with one root. All commits, reversions, branches and merges will operate on the tree that has just that single root. All branch switches and commit navigations will navigate to other parts of the tree. All rebases will reattach one part of the tree to another part that tree.

So, it appears that under no circumstance, will the "there is only one root" condition ever be broken. It is an invariant, and GitHub (as you suggested) is literally going out of its way to prevent what you're asking for.

So, you may have to create a fake root, attach A's root and B's root to it (along with the rest of their respective trees) and then merge their respective heads. Since I don't think there's any way you can dig under A's root to rebase it onto the fake root, then you may have to do this all within a new repository, instead of keeping it all in A.