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

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

On 14/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Catalin Marinas wrote:
> > 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).

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

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

--