"Alex Riesen" <raa.lkml@xxxxxxxxx> writes: > On 4/11/07, Alexander Litvinov <litvinov2004@xxxxxxxxx> wrote: >> >> What is --merge for ? Will the result be the same ? > > Maybe, maybe not. It uses merge strategies instead of git-am > and has advantages over blindly applying the patches (it can > know how a change got in, and it uses resolved conflict cache). I think "blindly applying the patches" is a gross overstatement, as merge-recursive will get confused the same way as git-apply, when a difference that comes from the two commits can be applied to two places. When the forward-ported change gets conflict, 3-way merge logic in "git-am -3" kicks in and does a fall back to merge-recursive on a reconstructed tree that has only the paths relevant to the case. With "format-patch piped to am-3", we could give the -M option to "format-patch" to deal with renames that happen in the series you are rebasing, but renames between the bases (the original base commit for the series and the new "onto" commit) is not something it can handle sensibly. That is the true advantage --merge has over "format-patch piped to am-3", as it always drives merge-recursive and it can notice renames between the two bases. But always driving merge-recursive is also its weakness. When the series being rebased is simple and long, especially on a big tree, applying many patches without conflicts tends to outperform running the same number of merges, as the patch application is tuned to take advantage of cache-tree while read-tree based merge essentially trashes cache-tree, and has to pay the full cost of write-tree for every commit it makes. Also there is that small D/F conflict problem merge-recursive has that I told you about, which does not exist in git-apply ;-) Did you have a chance to take a look at it yet? - 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