Re: [PATCH 2/5] Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()

From: Junio C Hamano <junkio@cox.net>
Date: Apr 8, 2007, 00:14 UTC
Message-ID: <7vfy7bbu3a.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704071456470.27922@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 16 quoted lines

> On Sat, 7 Apr 2007, Junio C Hamano wrote:
>
>> This fixes three buglets in threeway_merge() regarding D/F
>> conflict entries.
>> 
>> * After finishing with path D and handling path D/F, some stages
>>   have D/F conflict entry which are obviously non-NULL.  For the
>>   purpose of determining if the path D/F is missing in the
>>   ancestor, they should not be taken into account.
>> 
>> * D/F conflict entry is a phony entry and does not record the
>>   path being processed, so do not pick up the name from there.
>
> This bit is unnecessary, because the first bit means we treat D/F conflict 
> as missing in that conditional, and don't count it as an entry at all, let 
> alone one with a useful name.

I am not sure about what you mean by "first bit", but I added this after noticing there was a case where the path was not picked up from index/head/remote correctly because the "pick up the path from ancestors, while we check for any_anc_missing and no_anc_exists condition" loop at the beginning already set it to point at stages[i]->name (which is an empty string "" name of the df-conflict entry).

But I notice that "aggressive" codepath is the only thing that wants to use the path (it uses it to check the working tree status), so maybe we should move that path computation business inside the aggressive codepath.