On Fri, Mar 25, 2011 at 05:37:58AM -0400, Jeff King wrote: > It _almost_ works. The merge completes automatically, and the tweak ends > up in foo.h, as you expect. But the merge silently deletes the > placeholder revision.h! > > I suspect it is a problem of merge-recursive either not handling the > broken filepair properly, or perhaps reading too much into what a rename > means. I haven't dug further. Ah, found it. In process_renames, we explicitly call remove_file() on the source, which is assuming the rename did not come from a broken pair. What we actually want to do, I think, is to just take the changes from the renaming side literally. There's no point in doing a 3-way merge because the other side's changes will end up applied to the rename destination. It just happens that without break_opt, the renaming sides change is _always_ a deletion, or else it would not have been a rename candidate. So the current code is a special case for that rule. Now, as far as how to do that, I haven't a clue. I've been staring at merge-recursive code for 30 minutes. ;) -Peff -- 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