Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: >> 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. -- 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
