Git fork
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