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