GITFORMAT-LOOSE(5)

🌸 NAME 🌸

gitformat-loose — the Git loose object format, bestie 💖 (you're reading GITFORMAT-LOOSE(5) from the Git Manual, and yes it's as iconic as it sounds)

---

🎀 SYNOPSIS 🎀

$GIT_DIR/objects/[0-9a-f][0-9a-f]/*
$GIT_DIR/objects/object-map/map-*.map

---

💅 DESCRIPTION 💅

okay so loose objects are how Git stores individual objects, where literally every object is written as a separate file. one object, one file. that's the whole vibe ✨

Over the lifetime of a repository, objects are usually written as loose objects initially. Eventually, though, these loose objects get compacted into packfiles via repository maintenance — that's to improve disk space usage and speed up the lookup of these objects. glow-up era 💅

---

🦋 LOOSE OBJECTS 🦋

Each loose object contains a prefix, followed immediately by the data of the object. like, immediately immediately, no gap, no filler. The prefix contains <type> <size>\0. <type> is one of blob, tree, commit, or tag, and size is the size of the data (without the prefix) as a decimal integer expressed in ASCII.

The entire contents — prefix and data concatenated — is then compressed with zlib, and the compressed data is what actually gets stored in the file. The object ID of the object is the SHA-1 or SHA-256 (as appropriate) hash of the uncompressed data. yes, uncompressed. don't come for me, that's just how it is 😭

The file for the loose object is stored under the objects directory, with the first two hex characters of the object ID being the directory and the remaining characters being the file name. why, you ask? sharding ✨ it's done to shard the data and avoid too many files being in one directory, since some file systems perform poorly with many items in a directory. not every filesystem can handle a crowd, okay?

As an example, the empty tree contains the data (when uncompressed) tree 0\0 and, in a SHA-256 repository, would have the object ID 6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321 and would be stored under:

$GIT_DIR/objects/6e/f19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321

Similarly, a blob containing the contents abc would have the uncompressed data of blob 3\0abc. look at that little guy. precious 🥺

---

🌈 LOOSE OBJECT MAPPING 🌈

When the compatObjectFormat option is used, Git needs to store a mapping between the repository's main algorithm and the compatibility algorithm for loose objects — plus some auxiliary information. (auxiliary info: the side quest info 🧚)

The mapping consists of a set of files under $GIT_DIR/objects/object-map ending in .map. The portion of the filename before the extension is that of the main hash checksum (that is, the one specified in extensions.objectformat) in hex format.

git gc will repack existing entries into one file, removing any unnecessary objects, such as obsolete shallow entries or loose objects that have been packed. spring cleaning behavior 👑

The file format is as follows. All values are in network byte order and all 4-byte and 8-byte values must be 4-byte aligned in the file, so NUL padding may be required in some cases. Git always uses the smallest number of NUL bytes (including zero) that is required for the padding in order to make writing files deterministic. deterministic queen, we stan 🫶

⚠️ bestie the alignment is not a suggestion!! 4-byte and 8-byte values must be 4-byte aligned, and Git always uses the smallest number of NUL bytes (including zero) needed for the padding — that's what makes writing files deterministic.

• A header appears at the beginning and consists of the following:
  • A 4-byte mapping signature: LMAP
  • 4-byte version number: 1
  • 4-byte length of the header section (including reserved entries but excluding any NUL padding).
  • 4-byte number of objects declared in this map file.
  • 4-byte number of object formats declared in this map file.
  • For each object format:
    • 4-byte format identifier (e.g., sha1 for SHA-1)
    • 4-byte length in bytes of shortened object names (that is, prefixes of the full object names). This is the shortest possible length needed to make names in the shortened object name table unambiguous.
    • 8-byte integer, recording where tables relating to this format are stored in this index file, as an offset from the beginning.
  • 8-byte offset to the trailer from the beginning of this file.
  • The remainder of the header section is reserved for future use. Readers must ignore unrecognized data here. (mind your business, basically 🙈)
• Zero or more NUL bytes. These are used to improve the alignment of the 4-byte quantities below.
• Tables for the first object format:
  • A sorted table of shortened object names. These are prefixes of the names of all objects in this file, packed together to reduce the cache footprint of the binary search for a specific object name.
  • A sorted table of full object names.
  • A table of 4-byte metadata values.
• Zero or more NUL bytes.
• Tables for subsequent object formats:
  • A sorted table of shortened object names. These are prefixes of the names of all objects in this file, packed together without offset values to reduce the cache footprint of the binary search for a specific object name.
  • A table of full object names in the order specified by the first object format.
  • A table of 4-byte values mapping object name order to the order of the first object format. For an object in the table of sorted shortened object names, the value at the corresponding index in this table is the index in the previous table for that same object.
  • Zero or more NUL bytes.
• The trailer consists of the following:
  • Hash checksum of all of the above using the main hash.

---

🍓 metadata type field 🍓

The lower six bits of each metadata table contain a type field indicating the reason that this object is stored:

• 0 — Reserved.
• 1 — This object is stored as a loose object in the repository.
• 2 — This object is a shallow entry. The mapping refers to a shallow value returned by a remote server.
• 3 — This object is a submodule entry. The mapping refers to the commit stored representing a submodule.

Other data may be stored in this field in the future. Bits that are not used must be zero. no rogue bits, periodt 💀

---

🫶 GIT 🫶

Part of the git(1) suite.

---

and that's the page!! brought to you by Git 2.56.0, dated 2026-09-27 — mwah, go read your objects 💜