GIT-INDEX-PACK(1)

📦
version 2.56.0 · 28 versions
, in arch rolling

✨ GIT-INDEX-PACK 💅

okay bestie, so this is the git-index-pack page from the Git 2.56.0 manual, dated 2026-09-27, and it's literally all about building pack index files for existing packed archives. no cap, it's giving very specific but very useful energy. 🎀

🌸 NAME 🌸

git-index-pack — build a pack index file for an existing packed archive. periodt. 💖

🦋 SYNOPSIS 🦋

git index-pack [-v] [-o <index-file>] [--[no-]rev-index] <pack-file>
git index-pack --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
                  [--[no-]rev-index] [<pack-file>]

like, that's the whole vibe right there. ✨

🌈 DESCRIPTION 🌈

so basically this command reads a packed archive (.pack) from whatever file you point it at, builds a pack index file (.idx) for it, and — if you want — optionally writes a reverse-index (.rev) for that pack too. then you can take the packed archive plus the pack index and drop them into the objects/pack/ directory of a Git repository. iconic behavior, honestly. 💅

💖 OPTIONS 💖

okay here's the part where we go through every single flag, and i promise i'm not skipping a single one. 🫶

  • -v — be verbose about what's going on, including progress status. like it literally tells you what it's doing. love that for us. 👑
  • -o <index-file> — write the generated pack index into the specified file. without this option, the name of the pack index file is constructed from the name of the packed archive file by replacing .pack with .idx (and the program fails if the name of the packed archive does not end with .pack). so yeah, -o is your bestie if you don't want the default naming situation. ✨
  • --rev-index, --no-rev-index — when this flag is provided, generate a reverse index (a .rev file) corresponding to the given pack. if --verify is given, ensure that the existing reverse index is correct. takes precedence over pack.writeReverseIndex. so like, it overrides the config, iykyk. 💀
  • --stdin — when this flag is provided, the pack is read from stdin instead and a copy is then written to <pack-file>. if <pack-file> is not specified, the pack is written to the objects/pack/ directory of the current Git repository with a default name determined from the pack content. if <pack-file> is not specified, consider using --keep to prevent a race condition between this process and git repack. not me warning you about race conditions, but like, i am. 🙈
  • --fix-thin — fix a "thin" pack produced by git pack-objects --thin (see git-pack-objects(1) for details) by adding the excluded objects the deltified objects are based on to the pack. this option only makes sense in conjunction with --stdin. so like, don't use it alone, bestie. it's giving "read the room." 💅
  • --keep — before moving the index into its final destination, create an empty .keep file for the associated pack file. this option is usually necessary with --stdin to prevent a simultaneous git repack process from deleting the newly constructed pack and index before refs can be updated to use objects contained in the pack. so yeah, it's the lock file vibe, and it's lowkey essential. 🔥
  • --keep=<msg> — like --keep, create a .keep file before moving the index into its final destination. however, instead of creating an empty file, place <msg> followed by an LF into the .keep file. the <msg> message can later be searched for within all .keep files to locate any which have outlived their usefulness. so like, you can leave a little note for future you. cute. 🎀
  • --index-version=<version>[,<offset>] — this is intended to be used by the test suite only. it allows you to force the version for the generated pack index, and to force 64-bit index entries on objects located above the given offset. so like, test suite only, no cap. don't come for me if you use it for something else. 😭
  • --strict[=<msg-id>=<severity>...] — die if the pack contains broken objects or links. an optional comma-separated list of <msg-id>=<severity> can be passed to change the severity of some possible issues, e.g., --strict="missingEmail=ignore,badTagName=error". see the entry for the fsck.<msg-id> configuration options in git-fsck(1) for more information on the possible values of <msg-id> and <severity>. so like, you can customize how strict it is, which is very main character energy. 💜
  • --progress-title — for internal use only. set the title of the progress bar. the title is "Receiving objects" by default and "Indexing objects" when --stdin is specified. so like, internal use only, bestie. don't touch. 🙅‍♀️
  • --check-self-contained-and-connected — die if the pack contains broken links. for internal use only. again, internal use only. i'm just the messenger. 💀
  • --fsck-objects[=<msg-id>=<severity>...] — die if the pack contains broken objects, but unlike --strict, don't choke on broken links. if the pack contains a tree pointing to a .gitmodules blob that does not exist, prints the hash of that blob (for the caller to check) after the hash that goes into the name of the pack/idx file (see "Notes"). an optional comma-separated list of <msg-id>=<severity> can be passed to change the severity of some possible issues, e.g., --fsck-objects="missingEmail=ignore,badTagName=ignore". see the entry for the fsck.<msg-id> configuration options in git-fsck(1) for more information on the possible values of <msg-id> and <severity>. so like, it's strict but not that strict. we love nuance. 🌸
  • --threads=<n> — specifies the number of threads to spawn when resolving deltas. this requires that index-pack be compiled with pthreads, otherwise this option is ignored with a warning. this is meant to reduce packing time on multiprocessor machines. the required amount of memory for the delta search window is however multiplied by the number of threads. specifying 0 will cause Git to auto-detect the number of CPU's and use maximum 3 threads. so like, more threads = more speed but also more memory, and 0 is the "just figure it out" option. slay. ⭐
  • --max-input-size=<size> — die if the pack is larger than <size>. simple as that. no cap. 🔥
  • --object-format=<hash-algorithm> — specify the given object format (hash algorithm) for the pack. the valid values are sha1 and (if enabled) sha256. the default is the algorithm for the current repository (set by extensions.objectFormat), or sha1 if no value is set or outside a repository. this option cannot be used with --stdin. note: at present, there is no interoperability between SHA-256 repositories and SHA-1 repositories. historically, we warned that SHA-256 repositories may later need backward incompatible changes when we introduce such interoperability features. today, we only expect compatible changes. furthermore, if such changes prove to be necessary, it can be expected that SHA-256 repositories created with today's Git will be usable by future versions of Git without data loss. so like, SHA-256 is the future but it's not fully interoperable yet, and that's the tea. ☕
  • --promisor[=<message>] — before committing the pack-index, create a .promisor file for this pack. particularly helpful when writing a promisor pack with --fix-thin since the name of the pack is not final until the pack has been fully written. if a <message> is provided, then that content will be written to the .promisor file for future reference. see partial clone[1] for more information. also, if there are objects in the given pack that references non-promisor objects (in the repo), repacks those non-promisor objects into a promisor pack. this avoids a situation in which a repo has non-promisor objects that are accessible through promisor objects. requires <pack-file> to not be specified. so like, promisor packs are a whole thing, and this flag is very much for the partial clone girlies. 🧚

🎀 NOTES 🎀

once the index has been created, the hash that goes into the name of the pack/idx file is printed to stdout. if --stdin was also used then this is prefixed by either "pack\t", or "keep\t" if a new .keep file was successfully created. this is useful to remove a .keep file used as a lock to prevent the race with git repack mentioned above. so like, the output tells you what's up, and it's actually useful. 💖

👑 GIT 👑

part of the git(1) suite. you know the vibes. ✨

🌟 NOTES 🌟

  1. partial clone — file:///usr/share/doc/git-doc/technical/partial-clone.html

so yeah, that's the whole page, bestie. Git 2.56.0, dated 2026-09-27. now go forth and index those packs. you're gonna slay. 💅🦋🌸

📦 where this page comes from