On Tue, Jul 24, 2018 at 10:18:03AM -0700, Junio C Hamano wrote: > 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...?
Because we are doing a "git repack -ad" here. So we are considering _all_ of the objects, but avoiding making deltas between some of them. During an actual fetch, the islands are not used at all (but the delta relationships left on disk are important for letting us reuse those deltas as-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 try to account for this somewhat by looking at islands in the sort we do of the delta candidates. But to be honest, I am not sure how much sense that makes (but I did verify experimentally that it helps). Again, this is one of the reasons I had not sent this previously: I am not at all confident that it is doing the right thing in all places. -Peff
