Re: [PATCH (1b)] merge-recursive.c: Add more generic merge_recursive_generic()

Daniel Barkalow [off-list ref] writes:

quoted

Puhh, I've not dug into merging stuff that deep, but for me it does not
look that this can be done in a useful way, i.e. merge_working_tree()
does not do a recursive merge.

Ah, true. It's actually doing a single merge in the way that 
merge_recursive would do a single merge. I think it ought to be doing 
a recursive merge, but that's probably a change for later, anyway. (This 
is for -m, which essentially picks the uncommited changes versus the old 
branch, applied to the new branch uncommitted)

Why would you think it should be doing a recursive merge?  It shouldn't.

Think of builtin-merge-recursive.c::merge_trees() as a fancier version of
3-tree variant of "unpack_trees()", with -m and -u option.

When you want to perform an exact three-way merge (i.e. you have two
states O and B, and you want to apply changes between O and B to your
state A, and you _precisely_ know what O is) that's the interface you
would want to use, not the recursive one.  The recursive behaviour is
desirable only when you have A and B and need to infer where O should be,
and/or there are multiple O's to deal with (i.e. running "git-merge B"
when you are at A).

In all the potential users of merge-recursive machinery, namely, "revert",
"cherry-pick", "stash apply", "am -3", and "checkout -m", you know what
single common tree to use for your three-way merge.  These operations,
when done with direct C call into merge machinery, should NOT be using the
"recursive" one.

When you switch branches from A to B with checkout, and you have local
changes A', then you would want an exact three-way merge that modifies B
by applying changes from A to A'.

When you cherry-pick commit C on top of your current HEAD, you want an exact
three-way merge that modifies your HEAD by applying changes from C^ to C,
and you do not want the merge machinery to take ancestry relation (and
criss cross merges) between HEAD and C into account at all.

The scripted version of revert/cherry-pick used git-merge-recursive
because that is the Porcelain API available, and the current C-rewrite
uses it as well, but if we are rewriting it to call merge-recursive
machinery directly, it should be making a single merge request to
merge_trees(), not "recursive" one.