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

Hi,

On Thu, 14 Dec 2006, Catalin Marinas wrote:

On 13/12/06, Johannes Schindelin [off-list ref] wrote:

quoted

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.

Great!

What it the relation between git-merge-recursive and "git-read-tree
-m" (if any)?

git-merge-recursive internally calls the equivalent of 'git-read-tree -m' 
(it does not fork() and exec(), but rather calls the C functions 
directly) and does nothing more if the 'git-write-tree' succeeds. At least 
that's the theory...

If the git-write-tree does not succeed, it is because there are unmerged 
entries, and only then, merge-recursive does the rename detection and the 
file level merges.

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.

This is possible. However, it is not _that_ horrible to see "HEAD" and 
some SHA1 which is obviously non-HEAD. Added to that, a quite common case 
are the intermediate merges which make merge-recursive so powerful, and 
they are rightly called "Temporary branch 1" and "... 2".

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

Feasible, yes. But the code was written without that idea, so it would 
involve changes in the xdmerge_t structure (add i0, chg0), recording that 
in xdl_append_merge(), and passing also the base to 
xdl_fill_merge_buffer().

Is this really that nice? I never needed it... Besides, it can get really 
crappy when the conflicting regions are too large.

Ciao,
Dscho