What does “Auto packing the repository for optimum

问题:

I'm having a problem with my git repo. For the last couple of days whenever I do a push to the server I get this message: "Auto packing the repository for optimum performance", and it does not seem to go away and return the shell.

I also tried checking out to a new branch and then doing a rebase on my previous branch and then did git gc to remove the unused history objects and then did a push but still this message appears. Please let me know what's going on with my repo.

回答1:

Short version: it means what it says, and if you just let it finish, all will be well.

During most operations which can potentially increase the number of loose (unpacked) objects in the repository (including pushes), Git invokes git gc --auto. If there are enough loose objects (by default, at least 6700), it will then invoke git repack -d -l to pack them. If there are too many separate packs, it will also repack them into one.

A pack is a delta-compressed single file, containing a large number of objects. It's more efficient to store objects in packs, but it takes time to pack (compress) objects, so Git initially creates loose objects, then packs them in batches now and then, via automatic invocation of git gc --auto.

If you let Git finish repacking, this won't happen again for a while. It can indeed take a while, especially if you have a lot of large binary objects, but if it's triggering, then it's a sign that it will probably drastically reduce the amount of disk space taken by the repo. If you really don't want it to happen, you can change the config parameter gc.auto. If you increase it to something much larger than 6700, it will happen less frequently, but take longer when it does. If you decrease it, it'll still have to do your current repack, but subsequently it will happen more often and finish more quickly. If you set it to 0, it will disable automatic repacking.

See man git-gc (under --auto) and man git-config (under gc.auto) for more information.

回答2:

While Jefroni is correct that sometimes the auto-packing just needs time to complete, if the auto-packing message persists over multiple days as OP describes, there's a good chance that git's cleanup is missing dangling objects, as described in this question.

To see whether dangling objects are triggering ongoing messages about auto-packing, try running git fsck. If you get a long list of dangling commits, you can clean them with

git gc --prune=now

I usually have to run this on my repo every 2-3 months when the auto-packing message doesn't go away after a single pull.

回答3:

To disable for one project:

cd your_project_dir
git config gc.auto 0

To disable globally:

git config --global gc.auto 0

回答4:

Git is running git-repack, which packs many objects(=files, commits and trees) into one pack file. Git does this sometimes, when a heuristic says that there can be space saved (a pack file contains compressed object deltas, while each file in the objects/ directory contains the compressed full file content)

回答5:

Hopefully, that git gc --auto step is now (git 2.0.1, June 25th, 2014) more efficient.
See commit 62aad18 by Nguyễn Thái Ngọc Duy (pclouds)

gc --auto: do not lock refs in the background

9f673f9 (gc: config option for running --auto in background - 2014-02-08, Git 2.0.0) puts "gc --auto" in background to reduce user's wait time.
Part of the garbage collecting is pack-refs and pruning reflogs. These require locking some refs and may abort other processes trying to lock the same ref.

If gc --auto is fired in the middle of a script, gc's holding locks in the background could fail the script, which could never happen before 9f673f9.

Keep running pack-refs and "reflog --prune" in foreground to stop parallel ref updates. The remaining background operations (repack, prune and rerere) should not impact running git processes.