Git fixes quadratic pack loading slowdown in large monorepos

Git is set to regain fast pack loading after a regression that turned ordinary commands into multi-second waits in repositories with huge numbers of packfiles.

Johannes Schindelin reported that since a late-2025 change moved the list of packs into the packfile store, adding each pack walked the entire existing list to see whether it was already present and, if so, to move it to the end. Loading N packs therefore scaled as O(N²). In one Microsoft Git monorepo case with about 37,800 packs, a simple short-hash lookup of HEAD (the kind of call shell prompts make constantly) rose from roughly 0.4 seconds to 4.5 seconds.

Jeff King noted that Git had already solved quadratic pack loading once, in 2019, and that the project's own many-packs performance suite had shown a clear hit when the refactor landed. The suite is expensive to run and easy to ignore, he wrote, so the regression slipped through. Patrick Steinhardt said GitLab's continuous benchmarking likewise lacked a heavy pack-count case and would not have caught it.

Schindelin's fix adds a fast path for callers that already know a pack is new, so they skip the linear scan. Maintainer Junio C Hamano called the approach "clever and clean," provided the caller truly cannot already be on the list. Schindelin kept a conservative API so any in-flight or downstream callers that still need the uniqueness check are not broken.

An early claim that the same bug had stretched some CI clones from under two minutes to over half an hour was later withdrawn; that investigation continues separately. The everyday monorepo cost of loading many packs, including prompt-driven short-hash work, is the regression this change targets.