How to rebase one Git repository onto another one?
Solution 1
If A and B are not the same repo (you created B by using the latest working copy you had), you have to use a graft to pretend that they have common history.
Let’s assume you’ve added A as a remote for B as per VonC’s answer, and the repo looks like this1:
~/B$ git tnylog
* 6506232 (HEAD, master) Latest work on B
* 799d6ae Imported backup from USB stick
~/B$ git tnylog A/master
* 33b5b16 (A/master) Head of A
* 6092517 Initial commit
Create a graft telling the root of B that its parent is the head of A:
echo '799d6aeb41095a8469d0a12167de8b45db02459c 33b5b16dde3af6f5592c2ca6a1a51d2e97357060' \
>> .git/info/grafts
Now the two histories above will appear as one when you request the history for B. Making the graft permanent is a simple git filter-branch
with no arguments. After the filter-branch, though, you aren’t on any branch, so you should git branch -D master; git checkout -b master
.
1 git tnylog
= git log --oneline --graph --decorate
Solution 2
If A and B are the same repo (the first SHA1 are common), you can:
- declare A as a remote for B:
git remote add A /path/to/A
-
git fetch A
to update all remote A branches on the B repo -
git checkout dev
(on B, where you are developing) -
git rebase A/devBranch
to replay B (i.e. what you develop or re-develop from your backup) on top ofA/devBranch
(the development you lost). A bit like this SO question.
The last step allows you to sync your dev with the one you lost.
But actually, once you have fetch from A, you are done: B now contains the "all" history (the one you lost and your current work)
Solution 3
2021 Update
git filter-branch
has been deprecated since Git 2.24 (Q4 2019). Instead, for the scenario where A and B are not the same repo, you can use git replace --graft <commit> <parent>
.
See:
- "How do I combine several Git repositories without breaking file history?"
- "Git commands that could break/rewrite the history"
Solution 4
First of all, start by making a working clone of repo A.
Then simply pull into it from B and merge. You might prefer to create a new branch, pull onto it, then merge the two branches. You might also need a forcing flag; I've done things like this in Mercurial (grafting two apparently-unrelated repositories together) and it needs "-f".
Comments
-
kroimon about 3 years
I had one Git repository (A) which contains the development of a project until a certain point. Then I lost the USB stick this repo A was on. Luckily I had a backup of the latest commit, so I could create a new repository (B) later where I imported the latest project's state and continue development. Now I recovered that lost USB stick, so I have two Git repositories.
I think I just have to rebase repo B onto repo A somehow, but I have no idea how to do that, maybe using fetch/pull and rebase?
-
kroimon about 14 yearsThanks, seems to work, just have to resolve some conflicts during the merge/rebase now :)
-
VonC about 14 years@kroimon: conflicts were inevitable, I suppose, since you were re-developing in B some part of the code committed in A.
-
VonC about 14 years+1 for taking care of the "other scenario" were A and B differ completely in commit history.
-
Sedate Alien about 13 yearsThis was a brilliant help; did absolutely what I wanted with a minimum of fuss. Thank you!
-
Filip Dupanović about 13 yearsI just used the subtree-merge approach to stitch several repositories into one. I successively failed at the attempt to rebase them one over the other. Using graft points, I've now been able to stitch them onto a single development timeline, thanks!
-
Alberto almost 12 years+1 By the way, I edited your answer to reflect what your
git-tnylog
does (I was puzzled and took me a while until I found it was an alias of yours: 'Pimped tnylog a bit') -
Pim Jager over 8 yearsHow would you push this to a remote? Say I host my B on bitbucket and want to push this. Simply (--force) pushing a new commit to bitbucket doesn't (appear) to add the history of A to the the remote bitbucket.
-
Pim Jager over 8 yearsI already tried the command
git filter-branch 33b5b16dde3af6f5592c2ca6a1a51d2e97357060..HEAD
from link but then I can't push anymore since I get the error that the remote has unresolved deltas (remote: fatal: pack has 50 unresolved deltas
). -
Pim Jager over 8 yearsUpdate: after an hour of googling and using the rebasing option from this answer, I managed to create something which could be pushed to a new bare repo.
-
Alison S almost 7 yearsI ended up in a detached HEAD, and had to reference this: stackoverflow.com/a/25670296/1807668
-
VonC almost 7 years@AlisonS I agree: the rebase command was incorrect. If you have checked out
dev
, all you need isgit rebase A/devBranch
in order to replaydev
on top ofA/devBranch
. I have edited the answer. -
Admin about 6 years@PimJager (or anyone else with the same query), see: How to push a “git replace --graft”.
-
Admin about 6 years
-
timgeb about 3 yearsThis worked well for me without A and B having a common first SHA1. I did an interactive rebase and dropped some initial commits.