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

[Elijah Newren <newren@gmail.com>]

On Tue, Jun 29, 2010 at 1:54 AM, Miklos Vajna <vmiklos@frugalware.org> 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