How to combine two separate unrelated Git repositories into one with single history timeline

Question

I have two unrelated (not sharing any ancestor check in) Git repositories, one is a super repository which consists a number of smaller projects (Lets call it repository A). Another one is just a makeshift local Git repository for a smaller project (lets call it repository B). Graphically, it would look like this

A0-B0-C0-D0-E0-F0-G0-HEAD (repo A)
A0-B0-C0-D0-E0-F0-G0-HEAD (remote/master bare repo pulled & pushed from repo A)
A1-B1-C1-D1-E1-HEAD (repo B)

Ideally, I would really like to merge repo B into repo A with a single history timeline. So it would appear that I originally started project in repo A. Graphically, this would be the ideal end result

A0-A1-B1-B0-D1-C0-D0-E0-F0-G0-E1-H(from repo B)-HEAD (new repo A)
A0-A1-B1-B0-D1-C0-D0-E0-F0-G0-E1-H(from repo B)-HEAD (remote/master bare repo pulled & pushed from repo A)

I have been doing some reading with submodules and subtree (Pro Git is a pretty good book by the way), but both of them seem to cater solution towards maintaining two separate branch with sub module being able to pull changes from upstream and subtree being slightly less headache. Both solution require additional and specialized git commands to handle check ins and sync between master and sub tree/module branch. Both solution also result in multiple timelines (with subtree you even get 3 separate timelines when using --squash).

The closest solution from SO seems to talk about "graft", but is that really it? The goal is to have a single unified repository where I can pull/push check-ins, so that there are no more repo B, just repo A in the end.

Statutable

possible duplicate of How do you merge two git repositories? – Archimage

@MichaelDurrant No, I reject subtree & submodule solution as the scenario is not the same – Statutable

Answer 1

I think you do it like this:

1. git remote add [repo b]
2. git fetch//get the repo b into repo a
3. due to you want to keep the history like this: A0-A1-B1-B0-D1-C0-D0-E0-F0-G0-E1-H(from repo B)-HEAD (new repo A) you can first select the A0 as a start point, after that, use git cherry-pick one by one.

Hope this is useful for you.

Br, Tim

Garold

Combined your solution along with this guide @ gbayer.com/development/…, it works! – Statutable

you can cherry pick the full range using "git cherry-pick startHash^..lastHash" and use "git cherry-pick --continue" after each manual merge. – Gust

Answer 2

I did something similar (merge history from B into A) like this:

1. go to your repo A
2. git fetch <ref to your repo B> master:new-branch-on-A (so, you have copied master branch of B into a new branch 'new-branch-on-A' into your repo A.
3. git checkout new-branch-on-A
4. git rebase master (you rebase the new-branch-on-A with the master branch)
5. resolve conflicts if there are any
6. git checkout master
7. git merge new-branch-on-A
8. git branch -d new-branch-on-A
9. Done :), your histories are merged. I think all commits from A are before commit from B in the new history (git rebase -i is your friend if needed).

Unquiet

Answer 3

I believe the correct and most straightforward way of merging two unrelated histories is done with plain git merge --allow-unrelated-histories​.

• git-merge docs
• Step by step instructions & source of edited snippet, below

[From within the "new home" repository:] To combine the two repositories, first add the second repository as a remote to the first. Then, run git fetch to fetch its branch information:

git remote add repo-to-insert ../local/path/to/other/repo
git fetch repo-to-insert

Then, with the remote set up, merge the second repository’s history into the first using the --allow-unrelated-histories flag:

git merge repo-to-insert/branch-to-merge --allow-unrelated-histories
Merge made by the 'recursive' strategy.
 two.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 two.txt

Prone

You could improve your answer by adding more details of the steps involved, such as git remote add and git fetch to get both histories into a single repo before doing the git merge. – Mellott