Git Multi-Pack Index: Indexing Multiple Packfiles
Understand why Git uses a multi-pack index and safely create, verify, expire, and repack it in a disposable repository.
Advanced
Why a multi-pack index exists
Git repositories can accumulate multiple packfiles. Each pack normally has its own index, but looking up an object across many packs can become increasingly expensive. A multi-pack index stores object-to-pack lookup information across the set of packs, so Git can search that collection through one index structure instead of treating every pack index as an isolated lookup surface.
git count-objects -v
git multi-pack-index write
ls .git/objects/pack/multi-pack-indexQuick check
What problem does a multi-pack index primarily address?
Create a MIDX
The `write` subcommand creates or updates the multi-pack index for the repository’s pack directory. A useful laboratory starts with more than one pack so the purpose of the index is visible.
git multi-pack-index write
ls .git/objects/pack/
git count-objects -vWriting a MIDX does not merge all packs into one packfile. It adds an index over the existing pack set. That distinction matters: MIDX creation is an indexing operation, while repacking changes the physical pack layout.
Quick check
After `git multi-pack-index write`, what should you expect?
Verify the multi-pack index
Use `verify` to check the MIDX and the pack/index relationships it describes. This is storage-index verification, not a substitute for the broader object-integrity checks performed by `git fsck`.
git multi-pack-index verify
git fsck --fullQuick check
Which command is the dedicated MIDX verification operation?
Expire obsolete pack entries
A MIDX can retain references to packfiles that are no longer needed. `expire` removes packfiles that are no longer referenced by the current MIDX, according to the MIDX expiration rules. It is therefore a storage-maintenance operation, not a general reachability diagnosis.
git multi-pack-index expire
git multi-pack-index verifyRun expiration only when you understand which packfiles are disposable. In a learning lab, create the MIDX first and inspect the pack directory before and after each operation.
Quick check
What is the purpose of `git multi-pack-index expire`?
Repack through the MIDX
The MIDX `repack` subcommand selects packs for consolidation according to a batch-size limit and creates a new pack when the selection warrants it. Afterward, `expire` can remove packfiles that the new MIDX no longer needs.
git multi-pack-index repack --batch-size=1m
git multi-pack-index expire
git multi-pack-index verifyThe batch size is deliberately explicit in this lesson. It makes the selection policy visible in a disposable lab rather than presenting MIDX repacking as an opaque synonym for `git gc`.
Quick check
What does the MIDX `repack` operation primarily do?
MIDX is not the same as a single pack
A repository may have several packfiles and still have a valid MIDX. The point is to provide one cross-pack index, not to force the repository into one physical pack. Conversely, a repository with one pack does not need a MIDX for the same lookup-across-many-packs reason.
git count-objects -v
git multi-pack-index write
git multi-pack-index verifyQuick check
Which statement is correct?
Boundaries with nearby commands
V477 owns `git count-objects`, `git repack`, and `git verify-pack` as general pack-storage inspection. V476 owns `git fsck` for object connectivity and validity. V478 owns `git gc` and `git maintenance` for repository housekeeping. This lesson owns the MIDX subsystem specifically. Commit-graph files are a separate index subsystem and are intentionally not folded into this lesson.
git count-objects -v
git multi-pack-index verify
git fsck --full
git maintenance run --task=gcQuick check
Which command family should you choose to inspect whether the MIDX itself is structurally valid?
Practice what you learned
Use the dedicated Git code-completion exercise for this lesson.
Thanks for your feedback.
Mark this learning resource complete to track your learning progress.