Jeff King <p...@peff.net> writes:
> Here's a list of approaches I think we can use to fix this:
> 1. squelch the warning and ignore it. The downside here, besides not
> warning the user about true in-pack cycles, is that we have no
> opportunity to actually find a new delta (because we realize the
> problem only after the delta-compression phase).
> My test repository is a bad packing of all of the forks of
> torvalds/linux, with 3600 packs. I'm happy to share it if anybody
> wants to see it, but note that it is 11GB.
> The space overhead of the resulting pack in this case is ~3.2%
> (versus a pack generated by the original code, using the static
> pack order). Which is really not that bad, but I'm sure there are
> more pathological cases (i.e., there were on the order of hundreds
> or maybe thousands of cycles that needed broken, out of about 15
> million total objects; but one could imagine the worst case as
> So I dunno. I really like the MRU approach if we can salvage it.
I think I share the same feeling. As long as the chance is small
enough that the pack reordering creates a new cycle, the resulting
pack would not become too bloated by the last-ditch cycle breaking
code and finding a replacement delta instead of inflating it may not
be worth the trouble.
It worries me a lot to lose the warning unconditionally, though.
That's the (only) coal-mine canary that lets us notice a problem
when we actually start hitting that last-ditch cycle breaking too
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html