5

I've decided to retrospectively commit a history, that was never in Git, from an other old version control system. So I've created an orphan branch "newroot", and imported commits from the other version control system to it. Following question Insert a commit before the root commit in Git?

The "newroot" branch ended up with files exactly matching the root commit of the "master" branch.

Now I want to rebase the "master" branch onto the "newroot" orphan branch, like:

git rebase --onto newroot --root master

The problem is that I get prompted to resolve all merge conflicts. There are hundreds of merges over a span of many years. I'm just not capable of resolving them manually. And there's really no need, as these merges were already resolved in the past. As the rebase actually does not change contents (as I'm rebasing on an identical tree), I want Git to "replay the merge" exactly.

Is there a way to specify that the rebase should use the same resolution as was used previously?

I understood that the "rerere" may help here. But I would had to have it enabled already, when originally merging, right? Or can I retrospectively recreate the "rerere" cache?

I can imagine an alternative solution to my task. To somehow ask Git to concatenate the "newroot" and "master" branches, without actually rebasing. But I'm not sure if that's possible.

Community
  • 1
  • 1
Martin Prikryl
  • 188,800
  • 56
  • 490
  • 992

1 Answers1

6

To somehow ask Git to concatenate the "newroot" and "master" branches, without actually rebasing. But I'm not sure if that's possible.

That is called a graft point, followed by a filter-branch in order to rewrite master history.
See this post as an example or this question.

On the rebase side, you can try and use a merge strategy like theirs, to resolve any conflict using the master branch content (since master is being rebased)

git rebase --merge -s recursive -X theirs --onto newroot --root master
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your answer. The graft point looks like the solution I was after. Can you please explain why the `filter-branch` is needed and that does it do in a respect to the graft point? – Martin Prikryl Jun 29 '16 at 07:17
  • 1
    @MartinPrikryl graft point is a purely local trick to make a branch seen as the parent of another branch. You need filter-branch in order to make that trick permanent, as each SHA1 of master needs to reflect its new parent, starting with the first one (which would now have as parent the old imported branch). Again http://bugsquash.blogspot.fr/2010/03/stitching-git-histories.html shows a concrete example. – VonC Jun 29 '16 at 07:19
  • OK, so I add the graft point, and then when I call the `filter-branch`, it sees the graft point, and recreates the history according to the graft point. Afterwards, the graft point is no longer needed. Is that correct? – Martin Prikryl Jun 29 '16 at 07:23
  • @MartinPrikryl Yes, as described in http://bugsquash.blogspot.fr/2010/03/stitching-git-histories.html. The graft point won't be needed adter the filter-branch. The filter-branch will change the history which can be pushed. The graft point is purely local to your repo and will not be pushed, ever. – VonC Jun 29 '16 at 07:36