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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2007, 05:50 UTC
Message-ID: <7v644v5tr3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0707080248320.4093@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 8 quoted lines

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