Kristofer Karlsson's two-patch series adds an opt-in incremental mode for the connectivity check, enabled with transfer.connectivityCheck=incremental. It targets the slowdown that occurs as the number of objects reachable from the boundary grows. The verifier runs in the same rev-list subprocess that check_connected() already spawns, triggered by an internal --verify-trees-incremental flag. It follows an earlier RFC from Karlsson.

Patrick Steinhardt summarized the design as follows. Today everything, including trees and blobs, is marked uninteresting. The new approach skips that and compares the trees and blobs of the old tips with those of the new tips, verifying only what changed. He said this can verify significantly more objects in some scenarios, but cost scales with the number of changes rather than the number of existing objects, which he said he would really appreciate because marking reachable objects as uninteresting is extremely expensive.

Steinhardt also questioned whether adding more data sources, such as index entries and reflogs, would help. He said connectivity-check performance is mostly a server-side concern, where an index typically does not exist and reflogs are often absent. At GitLab, he said, repositories already have too many connectivity roots from refs alone, so more roots would probably make things worse.

In his documentation review he asked that the text spell out the reverse case: nothing can be assumed about objects not reachable from any reference, even if they already exist in the object database. He suggested wording that the check trusts objects reachable from references to be fully connected, and said he is wary of referring to code directly in the docs.

Junio Hamano, in a side note, wondered whether fsck should pay attention to connectivity roots other than refs, such as index entries.