Re: [PATCH] merge-tree: sometimes, d/f conflict is not an issue

Johannes Schindelin [off-list ref] writes:

quoted

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...