问题
When you want to rebase a branch keeping merge commits you pass the --preserve-merges flag. When you are merging unrelated history in git you need to pass the --allow-unrelated-histories flag.
If you are doing git rebase --preserve-merges when an existing merge comes from an unrelated history, it fails:
fatal: refusing to merge unrelated histories
If you try git rebase --preserve-merges --allow-unrelated-histories it fails with:
error: unknown option 'allow-unrelated-histories'
Is there some other way to tell rebase to allow the merge?
Edit: here is a minimal reproduction: https://github.com/vossad01/rebase-unrelated-merge-reproduction
To reproduce checkout master then execute:
git rebase --preserve-merges --onto origin/a-prime HEAD~2
回答1:
The brute-force method is to force a common root -- since you're trying to rebase roots, with no content history, make a nonce empty commit and tell git that's the parent of the histories you're merging:
git rev-list --all --max-parents=0 \
| awk '{print $0,empty}' empty=`:|git mktree|xargs git commit-tree` \
> .git/info/grafts
git rebase here
rm .git/info/grafts
回答2:
When git rebase fails on the merge it does not abort the rebase, so you have the opportunity to manually intervene.
If you are willing to to resolve this by hand, you can complete the merge as follows:
git merge --allow-unrelated ORIGINAL_BRANCH_THAT_WAS_MERGED --no-commit
git commit -C ORIGINAL_MERGE_COMMIT
git rebase --continue
Ideally, there would be a way for Git to handle this without manual intervention.
回答3:
To reproduce checkout master then execute:
git rebase --preserve-merges --onto origin/a-prime HEAD~2 -i
The git-rebase docs say to not combine -i and --preserve-merges.
[--preserve-merges] uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).
But even without the -i it still fails with fatal: refusing to merge unrelated histories.
Part of the problem is HEAD~2 is a direct ancestor of origin/a-prime. Your test repo looks like this:
1 [master]
|
2
|\
| | 3 [origin/a-prime]
| | |
| 4 / [origin/b]
| /
| /
|/
5 [origin/a]
HEAD~2 of master is 5. origin/a-prime is 3. Your command is equivalent to:
git rebase -p --onto 3 5
5 is a direct ancestor of 3, so that command doesn't make much sense. If that works at all, it's going to do something weird.
the cases I have encountered a couple of times recently have been in moving a project's documentation from GitHub Wiki to GitHub Pages (when the website already exists).
This is an inappropriate use of rebase. Rebase turns parallel histories into linear histories, basically pretending that one set of changes was done on top of another set all along. This is good for things like keeping feature branches up to date while they're being worked on, the bookkeeping and review is easier if you don't have a bunch of intermediate merge commits that do nothing but update the branch. Those are just noise to anyone reading the code and commit history in the future.
But when you have two truly divergent histories, it's best to leave them as divergent histories. Merging them tells the correct story: the web site and docs were developed separately, but then come together into one unit.
1 - 3 - 5
\
2 - 4 - 6 - 7 - 8 [master]
You can look at them separately in topological order (8, 7, 6, 5, 3, 1, 4, 2) using git log --topo-order or you can look at them interleaved in date order (8, 7, 6, 5, 4, 3, 2, 1), the git log default. A history visualizer like gitk or GitX will show both orders simultaneously.
Rebasing one on top of the other tells a lie: we worked on the site, and then we worked on the documentation, and then at some point (a point you'll have to find) and for some reason we worked on the site and documentation together.
1 - 3 - 5 - 2 - 4 - 6 - 7 - 8 [master]
That loses vital information and makes puzzling out why certain changes were made more difficult in the future.
Do a merge, it's the correct thing.
来源：https://stackoverflow.com/questions/43006544/allow-merging-unrelated-histories-in-git-rebase