Combining repositories #23811
-
There is a (and it seems not particularly rare) need sometimes to combine (I’ll avoid using the term “merge” for this) two repositories into a single repository so that we can then delete the original two and do all work on the new combined repository. This is discussed for example in this blogpost You’ll see a question I just asked on that blog and I’m repeating that question here: This is an interesting post and I have a question, does your solution cover the most genera case? Here’s what I mean. I have repo_a and repo_b. _ repo_a has branches master, gui_project and api_project branches_ In this scenario api_project has the same name in each repo because it is the same project, some code in repo_a and some in repo_b. I want to combine these and end up with repo_c that has 4 branches: master, gui_project, mem_project and api_project. where: _master contains all commits from master in repo_a and repo_b _ The repos are completely different, their folder structure and so on are unrelated so no folder/path/file hieracrchy appears in more than one repo, that is there is no code/files that is in each repo. This is my challenge, in repos where we have a lot of branches some unique to each repo and some with the same name in each repo because the work on them pertains to the same project. Now I know that GitHub doesn’t provide such a capability (be great if it did as this need often arises from time to time as projects or organizations grow and mature) but has anyone done this, in the general case that I outline above? In reality there a quite a lot more branches than just four, but this should be academic if we have a general solution. I want to attempt this but also want to gather as much input from others and git gurus before I actually begin, I’d hate to spend an hour or two then hit some roadblock simply because of a lack of due dilligence. Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
🚨 WARNING: At no point in what I describe below did I need to use Let me start by saying that you should protect yourself from data loss by using scratch repositories to perform your experiments. A scratch repository is one that is disconnected from all other repos so that you can’t possibly mess up anything but the scratch repo, but the various data sources that you’re using to build the scratch one are guaranteed intact. One of the nice things about git though is that it makes this pretty easy. If at any time you mess something up, just delete the entire local repository and start over. So here’s what I did, you can see the results in https://github.com/lee-dohm/merged-repo, which is a combination of https://github.com/lee-dohm/test-repo and https://github.com/lee-dohm/test-repo-2. I took your requirements:
To satisfy these requirements, I crated the following scenario:
First, I created a scratch repo:
Then, I hooked up the remotes:
Then, I needed to bring in all the source refs from the two repositories:
At this point, you can protect yourself from altering the source repos by deleting the remotes created:
Here’s how I merged the history of the
The key here, of course, being the
Rebasing each of the unique branches off of the local Then I created a new GitHub repository to host the merged results and pushed everything up:
I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
Lee, I greatly appreciate this, I will do a similar experiment and follow your directions and if that works out I’ll then try it with the two real repos. Many thanks. |
Beta Was this translation helpful? Give feedback.
-
3 posts were split to a new topic: Merge unrelated histories and keep parts unrelated |
Beta Was this translation helpful? Give feedback.
🚨 WARNING: At no point in what I describe below did I need to use
git push --force
. If you find yourself with the urge to usegit push --force
, then you are at risk of losing data and you should back out and start over.git push --force
is a potentially destructive command, use it at your own risk. 🚨Let me start by saying that you should protect yourself from data loss by using scratch repositories to perform your experiments. A scratch repository is one that is disconnected from all other repos so that you can’t possibly mess up anything but the scratch repo, but the various data sources that you’re using to build the scratch one are guaranteed intact. One of the nice things about git …