Jay Soffian <jaysoffian@xxxxxxxxx> writes: > On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: >> Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop. > > Well then I'm still confused. I see where pick_one() in > git-rebase--interactive.sh is using cherry-pick. > > But call_merge() in git-rebase.sh is using git-merge-recursive (absent > specifying another strategy). > > ? I think Dscho's point is that cherry-pick internally runs the same merge-recursive. 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. -- 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