From: Alex Riesen Date: Wed, 13 May 2009 11:33:33 GMT Subject: Re: [PATCH] Fix for a merge where a branch has an F->D transition Message-ID: <81b0412b0905130433x6aa780cbt61d99e9f3d0f2720@mail.gmail.com> In-Reply-To: 2009/5/13 Johannes Schindelin : > On Wed, 13 May 2009, Alex Riesen wrote: >> 2009/5/13 Junio C Hamano : >> > Alex Riesen 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... > Maybe the patch could live on master or next for while? Many people track master, so a performance degradation, if it happens, will be noticed. And with master (or even better - next) we have an auditory which is at least capable to complain.