On Thu, Feb 4, 2010 at 7:45 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I think Dscho's point is that cherry-pick internally runs the same > merge-recursive. Ah hah, that's what I was missing. Thank you. > When you have a change C based on its parent C^ and want to replay that > effect on a (possibly unrelated) commit A, you would run three-way merge, > merging C into A as if C^ is the common ancestor. The rebase script > cherry-pick, and revert all work with the same principle (for revert > obviously you would swap C and C^---you are applying the effect of going > from C to C^ in that case). > > And no, "format-patch --stdout | am -3" pipe in the normal rebase codepath > will stay unless you can produce a benchmark that says the performance of > merge machinery is good enough these days. Back when "rebase -m" was > introduced, it wasn't. Indeed, the difference is painful on a largish tree (910M after gc --aggressive, 39k files). Best of 3 runs for each of these: $ time git rebase --onto HEAD~11 HEAD~10 First, rewinding head to replay your work on top of it... [...] real 0m11.164s user 0m2.671s sys 0m4.836s $ time git rebase -m --onto HEAD~11 HEAD~10 [...] real 0m40.507s user 0m17.848s sys 0m16.052s $ time GIT_EDITOR="sed -i -e 1d" git rebase -i HEAD~11 [...] real 0m27.758s user 0m12.615s sys 0m13.134s It looks like there's room for improvement to rebase -m. (2.53 Ghz Core 2 Duo Macbook Pro, 4GB memory.) j. -- 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