Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> IOW, don't make unpack-trees to make policy decisions on final >> resolution, unless it is operating under aggressive rule (where the >> caller explicitly allows it to make more than the "trivial" decisions). >> The caller (in this case, merge-recursive) should see A at stage #2 with >> A/B at stages #1 and #3 and decide what to do. > > Okay, so you're saying that merge-recursive should use the aggressive > strategy? I do not think so. Isn't the whole "see if there are renames" thing depend on threeway_merge() not resolving "one side removes other side leaves intact" case itself? Aggressive resolves it saying "Ok that is a remove", which risks it to miss the case in which that the side that apparently "removed" the path in fact moved it somewhere else. The last time I looked at merge-recursive's D/F check, I found that it was not quite doing things right. I may be able to dig up what I posted to the list... - 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
