63

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?

Elnur Abdurrakhimov
  • 44,157
  • 10
  • 147
  • 130
kroimon
  • 1,953
  • 2
  • 18
  • 22

4 Answers4

68

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

Community
  • 1
  • 1
Josh Lee
  • 161,055
  • 37
  • 262
  • 269
  • 2
    +1 for taking care of the "other scenario" were A and B differ completely in commit history. – VonC Mar 11 '10 at 21:25
  • 3
    This was a brilliant help; did absolutely what I wanted with a minimum of fuss. Thank you! – Sedate Alien Feb 18 '11 at 02:41
  • 1
    I 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! – Filip Dupanović Apr 19 '11 at 14:55
  • 15
    +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'](https://github.com/jleedev/dotfiles/commit/dc70a0bbef6ab6c7afabd49d6b917adca66e7bf5)) – Alberto May 30 '12 at 16:59
  • How 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 Oct 13 '15 at 11:50
  • I already tried the command `git filter-branch 33b5b16dde3af6f5592c2ca6a1a51d2e97357060..HEAD` from [link](https://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html) 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 Oct 13 '15 at 12:27
  • Update: after an hour of googling and using the rebasing option from this [answer](http://stackoverflow.com/questions/13450131/how-to-properly-push-one-git-repository-over-another-on-codebasehq), I managed to create something which could be pushed to a new bare repo. – Pim Jager Oct 13 '15 at 13:45
  • 1
    @PimJager (or anyone else with the same query), see: [How to push a “git replace --graft”](https://stackoverflow.com/questions/42489421/how-to-push-a-git-replace-graft). –  Apr 12 '18 at 01:53
  • 1
    Related: [How do git grafts and replace differ? (Are grafts now deprecated?)](https://stackoverflow.com/questions/6800692/how-do-git-grafts-and-replace-differ-are-grafts-now-deprecated). –  Apr 12 '18 at 01:55
40

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 of A/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)

VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
  • Thanks, seems to work, just have to resolve some conflicts during the merge/rebase now :) – kroimon Mar 11 '10 at 21:13
  • @kroimon: conflicts were inevitable, I suppose, since you were re-developing in B some part of the code committed in A. – VonC Mar 11 '10 at 21:24
  • I ended up in a detached HEAD, and had to reference this: https://stackoverflow.com/a/25670296/1807668 – Alison S Jun 13 '17 at 23:01
  • @AlisonS I agree: the rebase command was incorrect. If you have checked out `dev`, all you need is `git rebase A/devBranch` in order to replay `dev` on top of `A/devBranch`. I have edited the answer. – VonC Jun 14 '17 at 05:56
  • This worked well for me without A and B having a common first SHA1. I did an interactive rebase and dropped some initial commits. – timgeb Mar 01 '21 at 12:30
4

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:

mefryar
  • 149
  • 3
  • 7
2

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".

crazyscot
  • 11,539
  • 2
  • 37
  • 40