Hi Martin, Martin von Zweigbergk wrote: > Interactive rebase uses cherry-pick internally. Jonathan added support > for -X to that command not too long ago (in commit 67ac1e1, late last > year), so it should be pretty straight-forward to add support for what > you want. Maybe I'll do that in a few weeks when I get back from > vacation. That would be excellent. > A related topic is _when_ to use the strategy (and strategy options). I agree with your analysis. In particular: > Example: > > X > \ > A---M---B > / > ---o---O---P---Q > > When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield > > X > \ > ---o---O---P---Q---A'---M'---B' I have a vague feeling that honoring --strategy and --strategy-option would be confusing here. The merge used in cherry-picking A does not have much to do with the merge used to reincorporate changes from X. Well, that is my intuition, but most of the examples I can think of lead to the opposite conclusion! If I use -Xrenormalize, because P changed the line-ending style, then I will want the same option when merging X on top. Similarly, if I use -Xsubtree=src, because Q moved all existing files in the source tree under src/, then with luck the same trick will work when replaying the merge of X. Luckily there is an exception to prove the intuition ok. If X was the first parent of M and I am using -Xours to sloppily favor upstream's decisions when rebasing my history on top of it, using -Xours to favor choices from X (which is my own) would be just plain wrong. (Phew.) > C---D > / \ > A---B---M > / > ---o---O---P---Q > > which would yield > > C'---D' > / \ > ---o---O---P---Q---A'---B'---M' Likewise in this case. > A more advanced solution would be recreate the merge using rerere. [...] Here's a vague and probably wrong idea about another way to re-create merges. When cherry-picking a patch (A, say), we run a three-way merge, with A^ as merge base, A as "their" change, and the new parent for A (= Q) as "our" change. Maybe the same trick could work for re-creating merges. In your first example, run a three-way merge with M^ (= A) as merge base, M as "their" change, and the new parent for M (= A') as "our" change. That only works in such a straightforward way if only one of M's parents was rewritten, though. More generally it could be possible to run a sequence of three-way merges: base=M^1, theirs=M, ours=(M^1)' => call the result "m_1" base=M^2, theirs=m_1, ours=(M^2)' => call the result "m_2" ... At this point it gets ugly enough that just redoing the merge might be simpler. The main problem with rerere is that it can make mistakes. In the long run, I wonder if rebase could learn to take into account something more explicit like Junio's merge-fix mechanism (see origin/todo:Reintegrate). Thanks; that was interesting. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html