Git unpack-objects: Expand Pack Archives into Loose Objects

Advanced

A pack archive can be expanded back into loose objects

Git normally stores newly created objects as individual loose files and can later compress them into pack files. `git unpack-objects` performs the reverse storage operation for a pack supplied on standard input: it expands the objects into the target repository as loose objects.

# In a repository containing objects, inspect its packs first.
git count-objects -v

# The command consumes a .pack file from standard input.
git unpack-objects < /path/to/archive.pack

?

Use it when the target repository does not already contain the objects

Objects that already exist in the target repository are not unpacked again. This makes the command useful when a pack contains objects missing from the destination, but it also means feeding a pack already stored in the destination will normally result in nothing new being written.

# Create a disposable repository and receive a pack produced elsewhere.
git init receiver
cd receiver

# Feed the pack to the receiver.
git unpack-objects < ../incoming.pack

# Confirm the object database now contains loose objects.
git count-objects -v

?

`--dry-run` checks without writing

`-n` / `--dry-run` validates the pack input without actually unpacking its objects. It is useful when the pack came from an untrusted or experimental source and you want to check it before changing the object database.

# Check the pack without writing objects.
git unpack-objects --dry-run < ../incoming.pack

# Short spelling: run the same kind of check.
git unpack-objects -n < ../incoming.pack

?

Progress output and quiet mode

Git can report percentage progress while unpacking. `-q` / `--quiet` suppresses that progress output. This changes presentation, not the resulting objects.

# Suppress progress output.
git unpack-objects --quiet < ../incoming.pack

# Equivalent short option.
git unpack-objects -q < ../incoming.pack

Strict validation

`--strict` tells Git not to write objects with broken content or broken links. This is an additional integrity guard when accepting a pack whose contents you do not want written unless the referenced object relationships and object data satisfy the stricter checks.

# Reject objects with broken content or links instead of writing them.
git unpack-objects --strict < ../incoming.pack

?

Recovery mode for a corrupt pack

`-r` asks Git to keep going when unpacking a corrupt pack instead of stopping at the first corruption. It is a recovery-oriented option: use it when the goal is to salvage as many objects as possible from damaged input, not as a substitute for integrity verification.

# Best-effort recovery from a corrupt pack.
git unpack-objects -r < ../possibly-corrupt.pack

?

Input size limits are a separate safety boundary

Current Git documentation also documents `--max-input-size=<size>` as an input-size limit. Because this curriculum verifies learner-facing commands against the installed Git 2.47.3, the lesson does not present that newer documented form as a required runnable exercise unless the local executable supports it.

Keep the pack/object responsibilities distinct

The surrounding plumbing commands form a useful storage pipeline. `git pack-objects` creates pack data; `git index-pack` builds an index for an existing pack; `git unpack-objects` expands a pack into loose objects; `git prune-packed` removes loose copies that are already safely represented in packs. These commands manipulate the same object storage but have different ownership and effects.

# Inspect the repository before and after storage changes.
git count-objects -v

# Creation side: produce a pack from selected objects.
git rev-list --objects --all | git pack-objects --stdout > objects.pack

# Expansion side: restore loose objects into another repository.
git unpack-objects < objects.pack

git count-objects -v

Practice what you learned

Use the dedicated Git code-completion exercise for this lesson.