Git rebase - 保留合并失败 [英] Git rebase --preserve-merges fails
问题描述
我有一个包含多个合并提交的（大）提交树，我想要重新绑定到另一个提交。做一个正常的rebase会导致git要求我解决合并冲突。我不想审查每个合并，因为这将是很多工作。在了解了--preserve-merges选项之后，该选项被整齐地解释为是你的朋友，在这里。 $ b
该名称代表重新使用记录的分辨率，顾名思义，它允许您让Git记住您是如何解决大块冲突的，以便下次看到相同的冲突时， Git可以自动为你解决它。
[...]如果你想采用一个你合并的分支并修复了一堆冲突，然后决定重新绑定它相反，您可能不必再次执行所有相同的冲突。
如果 rerere 已被启用，
git config --global rerere.ena在合并之前抽取真正的
，那么Git会记录你如何解决创建提交D时合并冲突，并且在后续重新分配期间遇到相同冲突时应用相同的分辨率。冲突仍然会打断rebase操作，但它会自动解决。所有你不得不做的是 git rebase --continue 。
然而，它看起来像<$ c在合并之前，$ c> rerere 还没有被激活，这意味着Git一定没有记录你第一次解决冲突的方式。在此阶段，您可以立即激活 rerere 并再次手动解决所有这些相同的冲突，或者使用 rerere-train.sh 脚本（参见博客文章）使用现有的历史记录预先播种 rerere 缓存。
I have a (large) commit tree that contains several merge commits that I want to rebase to another commit. Doing a normal rebase causes git to ask me to resolve merge conflicts. I didn't want to review each merge, because this would be a lot of work. After finding out about the --preserve-merges option, which is neatly explained here, I thought I found the perfect tool for this task. However, I cannot seem to get it to work properly. I have created a toy example that demonstrates the problem.
Starting from an empty folder, we first create a branch with a merge and another branch on which we will rebase.
A---B--
\ \
---C---D
\
---E
Where master refers to B, branch refers to D and goodbye-branch refers to E.
git init
echo Hello > Hello.txt
git add Hello.txt
git commit -m "Create Hello.txt (commit A)"
git tag start
echo World! >> Hello.txt
git commit -am "Change to Hello World (commit B)"
git checkout start
git checkout -b branch
echo Dave >> Hello.txt
git commit -am "Change to Hello Dave (commit C)"
git merge master
echo Hello World, Dave! > Hello.txt
git add Hello.txt
git commit -m "Merge branch master into branch (commit D)"
git checkout start
git checkout -b goodbye-branch
echo Goodbye > Goodbye.txt
git add Goodbye.txt
git commit -m "Add Goodbye.txt (commit E)"
Up to this point, everything went ok. There was a merge conflict, but we resolved it. Now we try to rebase branch onto E to end up with the following commit tree:
A---E----B'
\ \
C'---D'
git checkout branch
git rebase -p goodbye-branch
This end with the following error:
Auto-merging Hello.txt
CONFLICT (content): Merge conflict in Hello.txt
Automatic merge failed; fix conflicts and then commit the result.
Error redoing merge f567809e2cc91244cc7fdac210e1771dc75e4d86
The file contains the following content:
Hello
<<<<<<< HEAD
Dave
=======
World!
>>>>>>> 0437403c97f33f229e41ec9584ce891a50052e48
What am I doing wrong? I would expect git to be able to use commit D to resolve the merge conflict it encounters while rebasing.
I am using Git 1.9.4.msysgit.1, which is the most recent version right now.
TL; DR
The --preserve-merges flag simply tells git-rebase to try to recreate merge commits instead of ignoring them. It does not give git rebase the ability to remember how merge conflicts were resolved, i.e. it does not record conflict resolutions for future use. What you want to use for that is rerere.
In your toy example, the conflict arising during the rebase is exactly the same as the one you resolved during the preceding merge. If you had activated rerere before the merge, you wouldn't have had to resolve that conflict again during the rebase.
If you anticipate that you will merge, then rebase a branch, you should activate rerere so that, in the future, you only need to resolve a given merge conflict once, not multiple times.
Detailed explanation
Let's break down your toy example.
git init
echo Hello > Hello.txt
git add Hello.txt
git commit -m "Create Hello.txt (commit A)"
git tag start
echo World! >> Hello.txt
git commit -am "Change to Hello World (commit B)"
git checkout start
git checkout -b branch
echo Dave >> Hello.txt
git commit -am "Change to Hello Dave (commit C)"
So far, so good. Right before your first git merge command, your repo looks like this:
In commit A, Hello.text contains
Hello
In commit B, Hello.text contains
Hello
World!
And in commit C, Hello.text contains
Hello
Dave
Now, when you try to merge master into branch by running
git merge master
Git reports a merge conflict because it has no way of figuring out, on its own, whether the contents of Hello.txt after the merge should be
Hello
World!
Dave
or
Hello
Dave
World!
or something else...
You resolve that conflict by overwriting the contents of Hello.txt with Hello World, Dave!, staging your changes, and completing the merge commit.
echo "Hello World, Dave!" > Hello.txt
git add Hello.txt
git commit -m "Merge branch master into branch (commit D)"
Your repo now looks like this:
Then you run
git checkout start
git checkout -b goodbye-branch
echo Goodbye > Goodbye.txt
git add Goodbye.txt
git commit -m "Add Goodbye.txt (commit E)"
At that stage, your repo looks as follows:
Now you run
git checkout branch
git rebase -p goodbye-branch
but experience a conflict. Before explaining why this conflict arises, let's look at what your repo would look like if that git-rebase operation were successful (i.e. conflict free):
Now let's see why you run into the same conflict in Hello.txt as during your first merge; Goodbye.txt is not problematic in any way, here. A rebase can actually be decomposed in a sequence of more elementary operations (checkouts and cherry-picks); more on this at http://think-like-a-git.net/sections/rebase-from-the-ground-up.html.
Long story short... In the middle of your git rebase operation, your repo will look as follows:
The situation is very similar to that right before your first merge:
in commit B', Hello.text contains
Hello
World!
And in commit C', Hello.text contains
Hello
Dave
Then Git attempts to create merge B' and C', but a merge conflict arises for the exact same reason as the first merge conflict you experienced: Git has no way of figuring out whether the Dave line should go before or after the World! line. Therefore, the rebase operation grinds to a halt, and Git asks you to resolve that merge conflict before it can complete the rebase.
What you can do about it: use rerere
Git's rerere is your friend, here.
The name stands for "reuse recorded resolution" and as the name implies, it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you.
[...] if you want to take a branch that you merged and fixed a bunch of conflicts and then decide to rebase it instead - you likely won't have to do all the same conflicts again.
If rerere had been enabled,
git config --global rerere.enabled true
before the merge, then Git would have recorded how you resolved the merge conflict when creating commit D, and would have applied the same resolution when it encountered the same conflict during the subsequent rebase. The conflict would still have interrupted the rebase operation, but it would have been resolved automatically. All you would have had to do is git rebase --continue.
However, it looks like rerere wasn't already activated before the merge, which means Git must have kept no record of how you resolved the conflict the first time. At this stage, you can either activate rerere now and resolve all those same conflicts manually again, or use the rerere-train.sh script (see also this blog post) to use the existing history to pre-seed the rerere cache.
这篇关于Git rebase - 保留合并失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
