Re: [PATCH v2 5/7] merge-ort: defer recursing into directories when merge base is matched

From: Derrick Stolee <stolee@gmail.com>
Date: Jul 15, 2021, 17:14 UTC
Message-ID: <9dedcf3b-5484-89d6-6800-77e18dfa6ea3@gmail.com>
In-Reply-To: <CABPp-BGX-02M2Aw+Fw-bArNd5tOdp_sgcE_oRGiTDicNsgxdgA@mail.gmail.com>

On 7/15/2021 12:03 PM, Elijah Newren wrote:

> On Thu, Jul 15, 2021 at 7:43 AM Derrick Stolee <stolee@gmail.com> wrote:
>>
>> On 7/13/2021 3:33 PM, Elijah Newren via GitGitGadget wrote:
>>> From: Elijah Newren <newren@gmail.com>

...

Show 13 quoted lines

>>> +                 renames->trivial_merges_okay[side] &&
>>> +                 !strset_contains(&renames->target_dirs[side], pi.string)) {
>>
>> Does this last condition mean "this directory is not already a parent of a
>> chosen rename target"?
> 
> I'm not sure what you mean by "chosen" here.  If by "chosen" you mean
> "cached" (which comes from ort-perf-batch-11's caching of upstream
> renames from previously cherry-picked commits), then yes.
> 
> Perhaps it's worth noting that rename detection has not yet been run
> for this merge by the time we hit this logic, so the only renames we
> can know are the cached ones from a previous pick.

I was missing the interaction with the cached results, which now makes much more sense here.

Thanks, -Stolee