Jeff King <p...@peff.net> writes: > I think this is inherent in the scheme (we're losing some delta > opportunities). But I think it's also made worse because the delta > window gets clogged with candidates that are forbidden by the island > config.
Hmph, and the reason why objects that do not even belong to the same island to be usable as a base are in the object list in the first place is...? > Repacking with a big --window helps (and doesn't take as long > as it otherwise might because we can reject some object pairs based > on islands before doing any computation on the content). Ah, then yes, a large window with early culling based on the delta island criteria definitely sounds like the right solution to that problem. > I have replacement code (which we have been running in production) > that is more clever about the threshold, and also can handle gaps in > the continuity (so we might realize we need to send objects 1-5000, > then skip a few, then 5037-8000, and so on). That vaguely sounds similar to what folks at $DAYJOB runs in their Gerrit/jgit thing.
