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

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

On Thu, 14 Dec 2006, Catalin Marinas wrote:

quoted

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

OK, thanks (I imagined it might work like this).

quoted

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

From the StGIT perspective, it only does a three-way merge and passes
commit id to git-merge-recursive, hence the complicated naming.
However, it wouldn't be hard to modify StGIT to actually replace the
hashes in the file with meaningful names.

quoted

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

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

I think I only used the ancestor region for a mental representation of
what xdl_merge already produces :-) since emacs (nor diff3) wasn't
able to show the real differences. Probably no longer needed now.

Thanks for the explanations.

--