git rebase“--preserve-merges --onto”不保留合并

Question

使用git v1.7.1我试图同时对--preserve-merges和--onto功能进行重新绑定。最终结果似乎没有合并提交，因此看起来是线性的。我宁愿保留合并提交，原因与人们经常使用--preserve-merges（更容易看到逻辑上是一个单独功能并在其自己的分支中开发的提交组）相同。

我的主分支（目标为底垫）很无聊：

A-B-C

的特性分支我想从拿有已被合并到其子特性分支。像：

 X - Y 
/ \ 
V-W ------ Z 

其中Z是一个合并提交是特性分支的负责人，从拿地，X和Y分别在子特性分支。

我使用：git rebase --preserve-merges --onto C V Z

我想直到结束：

  X - Y 
     / \ 
A-B-C-W ------ Z 

但不是我越来越：

A-B-C-W-X-Y 

，由于Z是一个受冲突自由合并，代码的最终状态是正确的，但历史并不像我想的那样富有表现力。

有没有办法得到我想要的东西？

编辑地址@Bombe： 我写了一个bash脚本来构造我的例子。在我的系统上（使用git 1.7.1的RHEL 6.2），这证明了我的问题。

#! /bin/bash 
# start a new empty repo 
git init 
# make some commits on the master branch 
git checkout master 
touch A.txt; git add A.txt; git commit -m "add A.txt"; git tag Atag 
touch B.txt; git add B.txt; git commit -m "add B.txt"; git tag Btag 
touch C.txt; git add C.txt; git commit -m "add C.txt"; git tag Ctag 
# now build the feature branch 
# start at Btag (more or less arbitrary; point is it's before C) 
git checkout Btag 
git checkout -b feature 
touch V.txt; git add V.txt; git commit -m "add V.txt"; git tag Vtag 
touch W.txt; git add W.txt; git commit -m "add W.txt"; git tag Wtag 
# now a subfeature 
git checkout -b subfeature 
touch X.txt; git add X.txt; git commit -m "add X.txt"; git tag Xtag 
touch Y.txt; git add Y.txt; git commit -m "add Y.txt"; git tag Ytag 
# merge the subfeature into the feature 
# preserves branch history with --no-ff 
git checkout feature 
git merge --no-ff subfeature 
# the merge commit is our Z 
git tag Ztag 
# one more commit so that merge isn't the tip (for better illustration of Z missing later) 
touch postZ.txt; git add postZ.txt; git commit -m "add postZ.txt"; git tag postZtag 
# now do the rebase 
git rebase --preserve-merges --onto Ctag Vtag 
# optionally move the master branch forward to the top of feature branch 
git checkout master 
git merge feature 

底垫之前，我：

 X-Y 
    / \ 
    V-W-----Z-postZ 
/
A-B-C 

底垫后，我得到：

 X-Y 
    / \ 
    V-W-----Z-postZ 
/
A-B-C-W'-X'-Y'-postZ' 

注意缺少的Z和postZ” 'Y' 之间。

Answer 1

非常感谢Bombe和一位离线朋友指出这对一些人有用。凭借这种灵感，我现在能够回答我自己的问题。

简短回答：1.7.5.2之前的git版本会显示这种不良行为。

很长的回答：在git自己的源代码回购中，2011年4月28日提交c192f9c865dbdae48c0400d717581d34cd315fb8明确解决了这个问题。

引述提交的信息（由安德鲁·黄）：

git-rebase--interactive.sh: preserve-merges fails on merges created with no-ff 

'git rebase' uses 'git merge' to preserve merges (-p). This preserves 
the original merge commit correctly, except when the original merge 
commit was created by 'git merge --no-ff'. In this case, 'git rebase' 
will fail to preserve the merge, because during 'git rebase', 'git 
merge' will simply fast-forward and skip the commit. For example: 

       B 
      /\ 
      A---M 
      /
    ---o---O---P---Q 

If we try to rebase M onto P, we lose the merge commit and this happens: 

       A---B 
       /
    ---o---O---P---Q 

To correct this, we simply do a "no fast-forward" on all merge commits 
when rebasing. Since by the time we decided to do a 'git merge' inside 
'git rebase', it means there was a merge originally, so 'git merge' 
should always create a merge commit regardless of what the merge 
branches look like. This way, when rebase M onto P from the above 
example, we get: 

        B 
       /\ 
       A---M 
       /
    ---o---O---P---Q 

解决方案：得到的git的新版本，如果需要从源代码构建。

顺便说一句，我用git bisect来解决这个问题。真棒工具。

Answer 2

我刚刚尝试重新创建您的情况，并且我可以报告--preserve-merges似乎按照广告方式工作。当您提交Z时，只需发出：

git rebase --preserve-merges --onto C V 

这就是我所做的，它保留了合并提交。

Answer 3

我遇到了这个问题。注意我的git版本，它是1.7.10.2。

我正在做一个提交范围（通过它的SHA1散列标识）到一个分支的rebase，也缺乏最后的合并提交。

我的解决方案是将W重新设置为X到C（不保留合并），然后将Y，Z和postZ重新绑定到X'上。

希望这会有所帮助。