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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 14, 2006, 13:44 UTC
Message-ID: <Pine.LNX.4.63.0612141436170.3635@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <b0943d9e0612140331q4c3a32e2l361fd04375f091d7@mail.gmail.com>

Hi,

On Thu, 14 Dec 2006, Catalin Marinas wrote:

Show 6 quoted lines

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

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