From: Catalin Marinas Date: Thu, 14 Dec 2006 14:15:14 GMT Subject: Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base Message-ID: In-Reply-To: On 14/12/06, Johannes Schindelin 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. --