Audit Redundant Git Packs Before You Remove Anything

git pack-redundant hunts for pack files Git considers redundant, but it is deprecated and needs an explicit flag just to run. This guide runs the audit safely, keeping deletion out of the first pass, then points you at git gc for the job it was probably meant to do.

Allow about 10 minutes for a small repository, plus time to inspect any proposed deletion. The commands below assume a local clone and a shell. They do not need elevated privileges unless the repository itself is owned by another account. Run them as the repository owner where possible.

1. Confirm the version and repository

Check that you are in the intended repository and record the Git version:

cd /path/to/repository
git rev-parse --show-toplevel
git --version

On the reference machine this reports Git 2.43.0. The installed manual is for Git 2.43.0 and says that pack-redundant is scheduled for removal. The extra acknowledgement flag is therefore part of the working command on this installation, even though it is not shown in the synopsis.

2. Check whether the command will run

Run a read-only scan of all local packs with the required acknowledgement:

git pack-redundant --i-still-use-this --all

A repository with no pack files may fail with fatal: Zero packs found!. That is not evidence of redundant data. It means there is nothing for this command to inspect. A repository with redundant packs prints pack names, one per line, suitable for further processing.

Do not omit --i-still-use-this on this Git. Without it, the command exits with status 128 and reports that it is refusing to run. The flag does not enable a new algorithm or grant permission to delete anything; it only confirms that you understand the command is being removed.

3. Understand what the result means

--all considers every pack in the repository and ignores pack filenames supplied on the command line. Without --all, provide one or more pack filenames instead:

git pack-redundant --i-still-use-this .git/objects/pack/pack-EXAMPLE.pack

The filename is a placeholder. List the real files first if you need to work with a selected set:

find .git/objects/pack -maxdepth 1 -type f -name '*.pack' -print

The command also accepts object IDs on standard input. Objects supplied there are treated as already accounted for, so they are ignored when Git decides which packs are required. This is why the manual shows an unreachable-object workflow:

git fsck --full --unreachable | cut -d ' ' -f3 | git pack-redundant --i-still-use-this --all

This pipeline is an audit only. It does not remove unreachable objects or pack files. Its input format comes from git fsck, so do not replace the cut expression with guessed output parsing if your Git version reports a different format.

4. Inspect the candidate list before changing anything

Capture the proposed pack list and review it before letting any destructive command consume it:

git pack-redundant --i-still-use-this --all > /tmp/redundant-packs.txt
status=$?
printf 'pack-redundant exit status: %s\n' "$status"
if [ "$status" -eq 0 ]; then
    sed -n '1,120p' /tmp/redundant-packs.txt
fi

Use a temporary path that is private to your account if the repository layout or pack names could disclose sensitive information. An empty file with status zero means the scan found no redundant packs. A non-zero status needs investigation; do not pipe it straight to a remover.

Destructive action warning: the manual describes piping results to xargs rm. That deletes complete pack files and can damage the repository if the input is wrong, stale, or from the wrong directory. Do not use that example as a routine cleanup command. If you have a documented reason to remove a specific pack, make a verified backup of the repository first, stop processes that may be writing to it, and check the exact paths with git rev-parse --git-dir. There is no reliable undo for a deleted pack without a backup or a fresh clone.

5. Use Git's normal maintenance path instead

For the normal goal of reducing duplicate storage, verify the repository and run Git's garbage collection instead:

git status --short
git count-objects -vH
git gc

git gc can repack objects and remove duplicate storage at object level, which is the limitation called out by the pack-redundant manual. It may consume CPU, memory, and temporary disk space, and it changes repository internals. Avoid running it during another Git operation or while a process is writing to the same repository. It does not change committed files, branches, or remotes.

After it completes, check the result:

git count-objects -vH
git fsck --full

git fsck --full should finish without reporting broken objects. It can report unreachable objects in repositories where that is expected, so read the messages rather than treating every line as a failure. If maintenance causes a problem, stop using the clone and restore the verified backup or reclone it. Do not manually delete more files from .git/objects/pack while diagnosing it.

Common traps

• Running from the wrong directory: the command examines the repository Git selects. Confirm the top-level path before scanning.
• Confusing no packs with no redundancy: Zero packs found! is an error from an empty pack set, not a clean redundancy report.
• Forgetting alternate object databases: add --alt-odb when packs in alternate object database directories should not be required to cover objects in local packs.
• Expecting verbose output on standard output: --verbose writes statistics to standard error and has a small performance cost.
• Treating a filename list as harmless: the output is deliberately suitable for feeding to a remover. Review it as data before using it in another command.