Hi, 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... Ciao, Dscho