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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 8, 2007, 02:18 UTC
Message-ID: <Pine.LNX.4.64.0707080311280.4093@racer.site>
In-Reply-To: <Pine.LNX.4.64.0707080248320.4093@racer.site>

Hi,

On Sun, 8 Jul 2007, Johannes Schindelin wrote:

Show 10 quoted lines

> On Sat, 7 Jul 2007, Junio C Hamano wrote:
> 
> > 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?

To refine on that: from my (limited, I admit) understanding of the code, by the time it hits that "if (o->aggressive)", in case of a df conflict, the chance has long whizzed by to decide anything useful, since either head or remote were set to NULL. So they are no longer what they would have to be in order to make any sense.

Well, I try to cobble up a patch for merge-recursive like you suggested, and stay away from threeway_merge() as far as I can, for the rest of my life.

However, it feels somehow wrong that I have to check all the files in the unmerged index, when unpack_trees could have easily seen that the tree did not change between all (in that case, just one) ancestors and the remote, but that head has changed that path to a file, and head agrees with index on that, and remote can stay where it is with its darned directory.

Ciao, Dscho