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

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 13/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> xdl_merge(), as Git uses it, tries harder to find the true conflicts. So,
> if the files actually differ in only one line, just this line will be
> shown as conflict.

I gave the latest GIT a try and it works OK with StGIT.

This new merge looks much better than diff3 (or rcs merge) because it
only shows the true conflicts.

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.

Are there any other things to be aware if I completely replace the
"git-read-tree + diff3" with git-merge-recursive?

One nice addition to git-merge-recursive (probably only useful to
StGIT) would be more meaningful labeling of the conflict regions,
passed via a command line similar to the "diff3 -L" option. StGIT
generates "patched", "current" and "ancestor" labels with diff3.

Yet another nice feature would be the ancestor region (which diff3
doesn't add either but it gets added by emacs'
ediff-merge-files-with-ancestor function if you use the interactive
merge with StGIT).

--