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

From: Elijah Newren <newren@gmail.com>
Date: Jun 29, 2010, 12:52 UTC
Message-ID: <AANLkTimFBlWiK76quLW1TiUfueGISsW7ZIHgFUcFg4j8@mail.gmail.com>
In-Reply-To: <20100629075442.GB31048@genesis.frugalware.org>

On Tue, Jun 29, 2010 at 1:54 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:

Show 14 quoted lines

> 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