From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 13 May 2009 09:59:29 GMT
Subject: Re: [PATCH] Fix for a merge where a branch has an F->D transition
Message-ID: <alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302>
In-Reply-To: <81b0412b0905122338q774454cj65edfde3d73948e3@mail.gmail.com>

Hi,

On Wed, 13 May 2009, Alex Riesen wrote:

> 2009/5/13 Junio C Hamano <gitster@pobox.com>:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> >> Frankly, I'm not really sure. The solution came largely ... empirical
> >> way. IOW, I tried more or less random things which looked like they
> >> should fix the problem. So a review is very much appreciated. Please.
> >
> > I've always thought that D/F conflict logic in merge-recursive is placed
> > at the wrong processing phase.  IIRC, it enumerates potential D/F
> > conflicting paths before even attempting to process renames, and it is
> > easy to miss a path that was previously file going away as the result of a
> > clean merge (in which case it is ok to have a directory there as the
> > result of a merge for other paths).  This breakage could be a small
> > example of it.
> >
> > Regardless, I think your patch is a reasonable fix to go to the
> > maintenance track.  Thanks for looking into it.
> 
> I'm afraid the fix is not that simple: the "if" branch where the change
> is placed supposed to prevent updating files in the working tree
> which already have the same content as the merge's output.
> My change may force them to be updated regardless. I think...
> Johannes, you know this area the best, could you please have
> a look?

Sorry, no time at the moment...

Ciao,
Dscho