On Tue, Jun 29, 2010 at 1:54 AM, Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> wrote: > On Mon, Jun 28, 2010 at 07:12:15PM -0600, newren@xxxxxxxxx wrote: >> I'm a little uneasy with this change, mainly because I don't fully >> understand the rename processing logic (I was actually kind of surprised >> when I made these changes and it worked). Although I verified that >> these changes (and my others in this patch series) introduce no new >> breakages in the testsuite and even fix a known issue, I'm still not >> quite sure I follow the logic well enough to feel fully confident in >> this change. I'm particularly worried I may have neglected some closely >> related cases that I should have fixed but which may still be broken. > > Same here, I touched merge-recursive, but not this part of it, so others > will give you a better review, I'm sure. :) > > Other than that, I like it, thanks! Oh, it looks like I was off by a couple lines when trying to read the authorship out of git blame -C -C. You touched lines that were pretty close, but it looks like this if block was actually due to Alex. So I'll add him to the cc. Alex: I think the basic idea is just that the rename logic isn't aware that there may be higher stage entries in the index due to D/F conflicts; by checking for such cases and marking the entry as not processed, it allows process_entry() later to look at it and handle those higher stages. But I'm not sure if that's the right way to handle it, or if just having process_renames() should take care of clearing out the higher stage entries, or if something else entirely should be done. Thanks, Elijah -- 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