On 14/12/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html