From: Kristofer Karlsson <krka@spotify.com>
Date: Mon, 29 Jun 2026 12:59:18 GMT
Subject: Re: [PATCH v4 0/8] commit-reach: terminate merge-base walk when one side is exhausted
Message-ID: <CAL71e4PpxGMsZLQPasECy5Z89EQPoOtC4LrLb8VyAo-2oabXyg@mail.gmail.com>
In-Reply-To: <5ef694a3-9164-4ab4-8835-136439f6d267@gmail.com>

On Mon, 29 Jun 2026 at 14:40, Derrick Stolee <stolee@gmail.com> wrote:
>
> I agree with your reasoning, data-backed discovery, and the course of
> action to fix this. I'm happy that you're able to close the loop on
> this long-standing performance issue even with v1 generation numbers.

Sounds good, then I can continue with the approach of removing some code
(even though it will likely be a net addition in the end).

> > Do you see any cases I might be missing where removing the fallback
> > could cause problems?
> I don't see any other concerns here. You're right that if we were to
> have a different mode that changes the priority-queue ordering, then
> the side-exhaustion optimization cannot be trusted, but you will
> remove this possibility.
>
> It _may_ be worth mentioning this with a comment when initializing
> the queue order for the paint_queue, because the use of the queue
> requires topological ordering.

Yes my plan is to rewrite v5 in a few ways:
- update original documentation to note that infinite -> finite
   generation does not always hold
- add a test (or more than one) for this problem
- don't introduce the bug at any point
- add a commit to replace the disabled optimization with
   removal of the commit-date based ordering (+ doc update)

Thanks for helping with this,
Kristofer