Re: Performance regression in connectivity check during receive-pack (git 2.54)

On Tue, Jul 21, 2026 at 07:40:02AM -0700, Junio C Hamano wrote:

> Stepping back a bit, the 'rev-list' command used for the
> connectivity check is curious in multiple aspects.
> 
>  * On the surface, it looks as if the caller wants an enumeration of
>    all objects that appear in the range.  However, the caller is not
>    interested in the actual list of objects.  Instead, they are
>    interested only in a single bit: whether the traversal succeeds
>    or dies due to a missing object.  This is because the traversal
>    determines whether we need to fetch, or whether we are already up
>    to date, to decide whether the proposed 'fetch' is a no-op.  The
>    positive ends of the traversal represent what we are about to
>    fetch; if we already have all the objects needed to reach those
>    tips in our repository, we can do without actually downloading
>    anything [*].
> 
>  * A false positive answer to the question "does the traversal die
>    due to a missing object?" does not affect correctness, as this is
>    merely an optimization to save downloads (though a false negative
>    is unacceptable).
> 
> Given this non-standard use of the command, we can pass
> application-specific cues (such as "we are doing this traversal for
> a connectivity check") down to the machinery as a hint to help it
> optimize its operation, and I suspect that such a hint might have
> value.

Yeah, I think there may be some interesting opportunities for
optimization in check_connected(). But as you noted, it is sometimes
used for fetch asking "do we probably have all of these objects" but
also for strict connectivity checks for incoming objects. The quarantine
area triggers only for the latter (in this case receive-pack), so it
would not really help here.

IOW, I'd consider it a mostly orthogonal possible direction for
optimization (but still a potentially interesting one).

-Peff