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

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jun 30, 2010, 06:53 UTC
Message-ID: <AANLkTilJIh9V3kIhBnfm5Bunzbp7XdoYOOoVbku_u-8y@mail.gmail.com>
In-Reply-To: <AANLkTilggM9-vBabNvJiYMiQZyZtJMLhfWleYKvuJNMv@mail.gmail.com>

On Tue, Jun 29, 2010 at 17:55, Elijah Newren <newren@gmail.com> wrote:

Show 7 quoted lines

> On Tue, Jun 29, 2010 at 7:36 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> I cannot say much about your change... Are you sure about D/F conflict
>> detection, though? You just test if target mode not 0.
>
> Well, as far as this particular if-block is concerned, blame suggests
> that you and Miklos were responsible (I apologize if gmail screws up
> and inserts line wrapping)::

Don't just look at the blame output, look at what the commits actually changed. It's either a reformatting or a trivial change.

> With D/F conflicts, the files would be loaded into higher stages in
> the index (before it gets to process_renames()), which I detected via
> a non-zero mode.

This just detects if there was any conflict. Not specifically D/F or F/D.

> If there's a different way I should be checking for higher stage entries
> that still need to be resolved, I'd be happy to use it.

I'd expect a check for a file-to-directory (or back) mode change.