Alexander Litvinov <litvinov2004@xxxxxxxxx> writes: > I have found that rebase have (new) option : --merge > Looking at the code show me that regular rebase is a simply format-patch and > am but --merge (or -s) use some merge stratyegy to merge changes between two > commits into current head. > > What is --merge for ? Will the result be the same ? Regular "rebase" uses "format-patch" piped to "am -3", so if you do not have renames the file-level patch conflict can be resolved using the 3-way merge logic. However, because we do not give -M to format-patch, it does not deal with case where you have renames in the series of commits you are rebasing, nor where you have renames between the current base commit and the commit you are rebasing onto (the latter won't be solved with giving -M to format-patch anyway, so we do not even try). In cases involving such renames, giving --merge option would probably be nicer to work with. It invokes merge-recursive logic to deal with the renames. I find that the regular rebase without --merge is faster (at least it feels to me that it is, and I kind of understand why; patch application to write out a tree is optimized to take advantage of cache-tree extension, as opposed to merging three trees which clobbers it), when there is no patch conflict. Since most rebases do not involve patch conflict for me and seldom involve rebases, I almost never use --merge myself, but this would depend highly on personal taste and project. - 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