Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 14, 2006, 12:00 UTC
Message-ID: <20061214120028.GK1747@spearce.org>
In-Reply-To: <b0943d9e0612140331q4c3a32e2l361fd04375f091d7@mail.gmail.com>

Catalin Marinas <catalin.marinas@gmail.com> wrote:

Show 6 quoted lines

> 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.