Re: [PATCH] Fix for a merge where a branch has an F->D transition

From: Alex Riesen <raa.lkml@gmail.com>
Date: May 13, 2009, 11:33 UTC
Message-ID: <81b0412b0905130433x6aa780cbt61d99e9f3d0f2720@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0905131159180.5046@intel-tinevez-2-302>

2009/5/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

Show 27 quoted lines

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

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.