Re: [PATCH 4/5] merge_recursive: Fix renames across paths below D/F conflicts

On Tue, Jun 29, 2010 at 1:54 AM, Miklos Vajna [off-list ref] wrote:

On Mon, Jun 28, 2010 at 07:12:15PM -0600, newren@gmail.com wrote:

quoted

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