Git fork
at reftables-rust 53 lines 1.9 kB view raw
1gitformat-loose(5) 2================== 3 4NAME 5---- 6gitformat-loose - Git loose object format 7 8 9SYNOPSIS 10-------- 11[verse] 12$GIT_DIR/objects/[0-9a-f][0-9a-f]/* 13 14DESCRIPTION 15----------- 16 17Loose objects are how Git stores individual objects, where every object is 18written as a separate file. 19 20Over the lifetime of a repository, objects are usually written as loose objects 21initially. Eventually, these loose objects will be compacted into packfiles 22via repository maintenance to improve disk space usage and speed up the lookup 23of these objects. 24 25== Loose objects 26 27Each loose object contains a prefix, followed immediately by the data of the 28object. The prefix contains `<type> <size>\0`. `<type>` is one of `blob`, 29`tree`, `commit`, or `tag` and `size` is the size of the data (without the 30prefix) as a decimal integer expressed in ASCII. 31 32The entire contents, prefix and data concatenated, is then compressed with zlib 33and the compressed data is stored in the file. The object ID of the object is 34the SHA-1 or SHA-256 (as appropriate) hash of the uncompressed data. 35 36The file for the loose object is stored under the `objects` directory, with the 37first two hex characters of the object ID being the directory and the remaining 38characters being the file name. This is done to shard the data and avoid too 39many files being in one directory, since some file systems perform poorly with 40many items in a directory. 41 42As an example, the empty tree contains the data (when uncompressed) `tree 0\0` 43and, in a SHA-256 repository, would have the object ID 44`6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321` and would be 45stored under 46`$GIT_DIR/objects/6e/f19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321`. 47 48Similarly, a blob containing the contents `abc` would have the uncompressed 49data of `blob 3\0abc`. 50 51GIT 52--- 53Part of the linkgit:git[1] suite