Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote: > What it the relation between git-merge-recursive and "git-read-tree > -m" (if any)? I currently still use "git-read-tree -m" for some merges > because of the speed gain due to the --agressive option (really > noticeable when picking a patch from an older branch). Probably > git-merge-recursive cannot implement this since it needs to track > deletion/additions for rename detection. There is a difference; always has been, probably will be for a long time. read-tree -m performs some trivial merges in the index. Its manual page explains it in gory detail, but its the really trivial, basic three way merge rules: Given two trees X and Y and some so-called base B: * If X == Y == B for that file, take any of the three. * If X == Y, but not B, take X or Y. * If X changes a file, but Y == B for that file, take X. * If Y changes a file, but X == B for that file, take Y. I believe that the --agressive option has added some additional rules about trivial file deletes. However notice the all important rule is not handled by read-tree -m: * If X changes a file, Y also changes file, merge them to create Z. This is where read-tree -m punts and hands things off to merge-recursive, which needs to invoke diff3 (or now the internal xdl_merge). read-tree -m also currently does not handle file additions, mode changes, or renames/copies. All of which are a lot more expensive to compute and are slightly less common. So Git gets decent performance by going through the rather cheap read-tree -m, then falling back into the slower merge-recursive when read-tree -m punted. Given that I see about 50% of my merges succeed with just read-tree -m and the other half punt over to merge-recursive it just about balances out over several merges. > Are there any other things to be aware if I completely replace the > "git-read-tree + diff3" with git-merge-recursive? >From what I understand git-merge-recursive will do everything that git-read-tree -m will do, except its going to be slower doing the really common, stupid cases that git-read-tree -m can handle on its own. -- Shawn. - 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