From: Elijah Newren Date: Tue, 29 Jun 2010 12:52:07 GMT Subject: Re: [PATCH 4/5] merge_recursive: Fix renames across paths below D/F conflicts Message-ID: In-Reply-To: <20100629075442.GB31048@genesis.frugalware.org> On Tue, Jun 29, 2010 at 1:54 AM, Miklos Vajna wrote: > On Mon, Jun 28, 2010 at 07:12:15PM -0600, newren@gmail.com 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