On Montag, 11. Januar 2010, Junio C Hamano wrote: > I ended up doing this myself. As we are dropping the postimage and adding > a new MERGE_RR entry, I also think that it is safer to update the preimage > with the conflict we got for this round, so I added that as well. Thank you, it appears to work as expected. It is actually very important to update the preimage as well, otherwise, the new postimage can contain unrelated additional changes. > However, I think there is a room for improvement in preimage handling. > > Currently, the rerere database is indexed with the conflict hash and for > each conflict hash you can record a single preimage-postimage pair to > replay. But you can have conflicts with the same conflict hash, but with > slightly different contexts outside the conflicted region, and the right > resolution can be different depending on the outside context. I did encounter a case where the same resolution would apply to all conflicts that have the same conflict hash, so it's not quite what you talk about. But not all conflicts were automatically resolved. I haven't yet analyzed what happened - it could just be that the xdl_merge call fails due to the differences in the text immediately outside the conflict markers. > In the traditional implementation, I punted this issue by noticing > conflicts in the three-way merge between pre, post and this images. If > preimage is too different from the conflicted contents we got during this > merge, then the previous resolution should not apply. > > But I think the right solution would be to have more than one preimage and > postimage pairs (preimage.0 vs postimage.0,... etc.) and try to use each > of them in handle_path() until it finds one that can be used to cleanly > merge with the conflict we got in thisimage during this round. The situation happens rarely, so I don't know if we should care. OTOH, *when* the situation arises, and a recorded resolution is applied incorrectly, it may be quite annoying. Dunno. -- Hannes -- 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