GIT-MULTI-PACK-INDEX(1)

📦
version 2.56.0 · 28 versions
, in arch rolling

🎀 GIT-MULTI-PACK-INDEX 💅

okay bestie, so this is the git-multi-pack-index page from the git manual — it lives in section 1, and it's all about writing and verifying multi-pack-indexes. yes, the MIDX. the main character of pack management. let's get into it 🫶

✨ NAME ✨

git-multi-pack-index — write and verify multi-pack-indexes. that's it, that's the whole vibe. 💖

🌸 SYNOPSIS 🌸

git multi-pack-index [<options>] write [--preferred-pack=<pack>]
                         [--[no-]bitmap] [--[no-]incremental] [--[no-]stdin-packs]
                         [--refs-snapshot=<path>] [--[no-]write-chain-file]
                         [--base=<checksum>]
git multi-pack-index [<options>] compact [--[no-]incremental]
                         [--[no-]bitmap] [--base=<checksum>] [--[no-]write-chain-file]
                         <from> <to>
git multi-pack-index [<options>] verify
git multi-pack-index [<options>] expire
git multi-pack-index [<options>] repack [--batch-size=<size>]

🦋 DESCRIPTION 🦋

Write or verify a multi-pack-index (MIDX) file. literally that's the job. no cap. ✨

💜 OPTIONS 💜

These command-line options work across all the sub-commands, so jot these down once and you're set, bestie:

  • --object-dir=<dir> — use the directory you give here as the location for Git objects. we go check <dir>/packs/multi-pack-index for the current MIDX file, and <dir>/packs for the pack-files we're gonna index.

heads up: <dir> must be an alternate of the current repository. that's a hard requirement, ngl.

  • --progress, --no-progress — turn progress on/off explicitly. if you don't say either one, progress shows up when standard error is connected to a terminal. supported by the write, verify, expire, and repack sub-commands. 🫶

The following subcommands are available (aka the lineup 👑):

⭐ write ⭐

Write a new MIDX file. the options below are the write sub-command's little squad:

  • --preferred-pack=<pack> — when you specify this, ties get broken in favor of this pack when there are additional copies of its objects in other packs. ties for objects that aren't found in the preferred pack always get resolved in favor of the copy in the pack with the highest mtime. if you don't specify anything, the pack with the lowest mtime is the default. also: the preferred pack must have at least one object. non-negotiable 💅
  • --[no-]bitmap — control whether or not a multi-pack bitmap gets written. your call, bestie.
  • --stdin-packs — write a multi-pack index containing only the set of line-delimited pack index basenames you feed in over stdin. very curated. very exclusive. 🎀
  • --refs-snapshot=<path> — with --bitmap, you can optionally specify a file containing a "refs snapshot" taken prior to repacking.

a reference snapshot is composed of line-delimited OIDs corresponding to the reference tips, usually taken by git repack prior to generating a new pack. a line may optionally start with a + character to indicate that the reference which corresponds to that OID is "preferred" — peep git-config(1)'s pack.preferBitmapTips.

the file given at <path> is expected to be readable, and it can contain duplicates. (if a given OID shows up more than once, it's marked as preferred if at least one instance of it begins with the special + marker.) 🍓

  • --incremental — write an incremental MIDX file containing only objects and packs not present in an existing MIDX layer. migrates non-incremental MIDXs to incremental ones when necessary. slay ✨
  • --[no-]write-chain-file — when used with --incremental, write a new MIDX layer but do not update the multi-pack-index-chain file. the checksum of the new layer gets printed to standard output, so the caller can assemble and write the chain itself. requires --incremental. (this is the DIY option, lowkey iconic)
  • --base=<checksum> — specify the checksum of an existing MIDX layer to use as the base when writing a new incremental layer. the special value none indicates the new layer should have no base (i.e., it becomes a root layer). requires --no-write-chain-file. 🌈

💫 compact 💫

Write a new MIDX layer containing only objects and packs present in the range <from> to <to>, where both arguments are checksums of existing layers in the MIDX chain.

  • --incremental — write the result to a MIDX chain instead of writing a stand-alone MIDX.
  • --[no-]bitmap — control whether or not a multi-pack bitmap gets written.
  • --[no-]write-chain-file — when used with --incremental, write a new compacted MIDX layer but do not update the multi-pack-index-chain file. the checksum of the new layer is printed to standard output. requires --incremental.
  • --base=<checksum> — specify the checksum of an existing MIDX layer to use as the base for the compacted result, instead of using the immediate parent of <from>. the special value none indicates the result should have no base.
⚠️ note that the compact command requires writing a version-2 midx that cannot be read by versions of Git prior to v2.54. so like, if your friends are on ancient git, they're not gonna see your compacted result. 💀

🧚 verify 🧚

Verify the contents of the MIDX file. vibe check for your index 💅

🌸 expire 🌸

Delete the pack-files that are tracked by the MIDX file, but have no objects referenced by the MIDX (with the exception of .keep packs and cruft packs). rewrite the MIDX file afterward to remove all references to these pack-files. basically clearing out the clutter, we love a clean slate ✨

💀 Note: this mode is incompatible with incremental MIDX files. like, don't even try it.

👑 repack 👑

Create a new pack-file containing objects in small pack-files referenced by the multi-pack-index.

if the size given by the --batch-size=<size> argument is zero, then create a pack containing all objects referenced by the multi-pack-index. for a non-zero batch size, select the pack-files by examining packs from oldest-to-newest, computing the "expected size" by counting the number of objects in the pack referenced by the multi-pack-index, then divide by the total number of objects in the pack and multiply by the pack size. we select packs with expected size below the batch size until the set of packs have total expected size at least the batch size, or all pack-files are considered. if only one pack-file is selected, then do nothing. if a new pack-file is created, rewrite the multi-pack-index to reference the new pack-file. a later run of git multi-pack-index expire will delete the pack-files that were part of this batch. fr fr, that's the whole flow 🫶

if repack.packKeptObjects is false, then any pack-files with an associated .keep file will not be selected for the batch to repack.

💀 Note: this mode is incompatible with incremental MIDX files. same deal as expire, bestie.

🍓 EXAMPLES 🍓

  • Write a MIDX file for the packfiles in the current .git directory.
$ git multi-pack-index write
  • Write a MIDX file for the packfiles in the current .git directory with a corresponding bitmap.
$ git multi-pack-index write --preferred-pack=<pack> --bitmap
  • Write a MIDX file for the packfiles in an alternate object store.
$ git multi-pack-index --object-dir <alt> write
  • Verify the MIDX file for the packfiles in the current .git directory.
$ git multi-pack-index verify

🌈 SEE ALSO 🌈

go read The Multi-Pack-Index Design Document[1] and gitformat-pack(5) if you want more info on the multi-pack-index feature and its file format. iykyk 💖

🎀 GIT 🎀

Part of the git(1) suite. obviously. family ties ✨

🦋 NOTES 🦋

  1. The Multi-Pack-Index Design Document file:///usr/share/doc/git-doc/technical/multi-pack-index.html

and that's the page, bestie!! 🫶 this whole thing ships with Git 2.56.0, dated 2026-09-27 — go forth and index your packs, you absolute icon 💅👑💖

📦 where this page comes from