I noticed that our repo’s .git/objects/pack/ folder has a giant .pack file (over 300MB). This makes the whole repo really big, which slows down things like cloning and pulling, and could make it inconvenient for contributors.
The big problem:
Because this repo is so large, it can noticeably slow down tools that depend on it. For example, when users add the Java plugin with asdf plugin-add java, asdf needs to clone or fetch this repo. The extra size means longer download times and a slower, less smooth experience—especially for people with slower internet connections.
Possible reasons:
At some point, big files (like JARs, archives, or other binaries) might have been committed, even if they were later deleted—they still stick around in the history.
Sometimes large files are changed repeatedly, and every version stays in the history.
Loads of old branches or tags can also add up.
If we don’t run git gc (garbage collect) regularly, old objects just keep piling up.
I noticed that our repo’s .git/objects/pack/ folder has a giant .pack file (over 300MB). This makes the whole repo really big, which slows down things like cloning and pulling, and could make it inconvenient for contributors.
The big problem:
Because this repo is so large, it can noticeably slow down tools that depend on it. For example, when users add the Java plugin with asdf plugin-add java, asdf needs to clone or fetch this repo. The extra size means longer download times and a slower, less smooth experience—especially for people with slower internet connections.
Possible reasons:
At some point, big files (like JARs, archives, or other binaries) might have been committed, even if they were later deleted—they still stick around in the history.
Sometimes large files are changed repeatedly, and every version stays in the history.
Loads of old branches or tags can also add up.
If we don’t run git gc (garbage collect) regularly, old objects just keep piling up.