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.
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
来源：https://stackoverflow.com/questions/38092355/resolve-git-rebase-conflicts-the-same-way-they-were-resolved-previously