Hi, Thanks for all the feedback. On Tue, Mar 1, 2011 at 12:31 PM, Jeff King <peff@xxxxxxxx> wrote: ... > As you mention, this second testcase is not a regression at all, and > while it would be great if we could avoid touching those files at all, I > don't think anybody will be too upset at files being rewritten that were > actually involved in the conflict. Well, technically they weren't involved in a conflict. One side had an unmodified directory of files, the other side removed that directory and just put a file there. Someone starts the merge on the side that only has a file there. There's no conflict, but we update the file. Still, it's a lot better than erroring out and claiming there was a conflict, so it's still an improvement over what we had. > I think the fix you have for the first testcase is reasonable. It feels > a little like a band-aid, as we are throwing away stat information early > on and then pulling it again from the filesyste at the end. But from > your description, the real fix to that would probably involve some > changes to the way unpack_trees works, and that's probably complex > enough that the band-aid is a good fix for now. I agree, it does seem like a bit of a band-aid, but as you say I was worried about the complexity of changing unpack_trees and wanted a good interim fix. Of course, Junio's point about deleted-as-unmodified files might be sticky enough that we have to start looking at such alternatives or do something more. We'll have to see what he says. -- 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