Subject: Re: [PATCH 3/3] commit-reach: optimize queue scan in ahead_behind

From: Jeff King <[email-masked]>
Date: Mon, 25 May 2026 03:11:50 -0400

On Sun, May 24, 2026 at 05:42:20PM +0000, Kristofer Karlsson via GitGitGadget wrote:

> ahead_behind() already deduplicates queue entries using the PARENT2
> flag (via insert_no_dup), so the counter is maintained through
> insert_no_dup() and mark_stale() using PARENT2 as the queued_flag.

That makes sense, but it does raise one question: since we do not clear
the PARENT2 flag upon popping, is it possible to consider a commit a
second time, after it has been popped?

I suspect the answer is "yes", if you have commits with out-of-order
dates (so we visit X, which has PARENT2 set, and then later visit its
descendant, and try to add X again as a parent).

I guess your counter does not make anything worse, though, because the
same PARENT2 flag that prevents us from incrementing the counter also
prevents us from actually adding it to the queue again.

And I think the current code is OK because we do not care about
de-duping the queue, but about not double-counting commits in the global
space. So PARENT2 effectively acts as a "seen" flag here.

-Peff