2009/5/13 Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > On Wed, 13 May 2009, Alex Riesen wrote: >> 2009/5/13 Junio C Hamano <gitster@xxxxxxxxx>: >> > Alex Riesen <raa.lkml@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html