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

Hi,

On Sat, 7 Jul 2007, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

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.

Yes, I realized that by running the tests with it.  A rename A->B in one, 
and A->C in the other branch will go undetected.

I should have written this into my mail posting the WIP patch, but 
frankly, I was too tired.

Ciao,
Dscho