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