Skip to content

Commit ca05bfb

Browse files
bk2204gitster
authored andcommitted
rust: add a new binary object map format
Our current loose object format has a few problems. First, it is not efficient: the list of object IDs is not sorted and even if it were, there would not be an efficient way to look up objects in both algorithms. Second, we need to store mappings for things which are not technically loose objects but are not packed objects, either, and so cannot be stored in a pack index. These kinds of things include shallows, their parents, and their trees, as well as submodules. Yet we also need to implement a sensible way to store the kind of object so that we can prune unneeded entries. For instance, if the user has updated the shallows, we can remove the old values. For these reasons, introduce a new binary object map format. The careful reader will notice that it resembles very closely the pack index v3 format. Add an in-memory object map as well, and allow writing to a batched map, which can then be written later as one of the binary object maps. Include several tests for round tripping and data lookup across algorithms. Note that the use of this code elsewhere in Git will involve some C code and some C-compatible code in Rust that will be introduced in a future commit. Thus, for example, we ignore the fact that if there is no current batch and the caller asks for data to be written, this code does nothing, mostly because this code also does not involve itself with opening or manipulating files. The C code that we will add later will implement this functionality at a higher level and take care of this, since the code which is necessary for writing to the object store is deeply involved with our C abstractions and it would require extensive work (which would not be especially valuable at this point) to port those to Rust. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent f15c9f9 commit ca05bfb

File tree

5 files changed

+994
-0
lines changed

5 files changed

+994
-0
lines changed

Documentation/gitformat-loose.adoc

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@ SYNOPSIS
1010
--------
1111
[verse]
1212
$GIT_DIR/objects/[0-9a-f][0-9a-f]/*
13+
$GIT_DIR/objects/object-map/map-*.map
1314
1415
DESCRIPTION
1516
-----------
@@ -48,6 +49,83 @@ stored under
4849
Similarly, a blob containing the contents `abc` would have the uncompressed
4950
data of `blob 3\0abc`.
5051
52+
== Loose object mapping
53+
54+
When the `compatObjectFormat` option is used, Git needs to store a mapping
55+
between the repository's main algorithm and the compatibility algorithm for
56+
loose objects as well as some auxiliary information.
57+
58+
The mapping consists of a set of files under `$GIT_DIR/objects/object-map`
59+
ending in `.map`. The portion of the filename before the extension is that of
60+
the main hash checksum (that is, the one specified in
61+
`extensions.objectformat`) in hex format.
62+
63+
`git gc` will repack existing entries into one file, removing any unnecessary
64+
objects, such as obsolete shallow entries or loose objects that have been
65+
packed.
66+
67+
The file format is as follows. All values are in network byte order and all
68+
4-byte and 8-byte values must be 4-byte aligned in the file, so the NUL padding
69+
may be required in some cases. Git always uses the smallest number of NUL
70+
bytes (including zero) that is required for the padding in order to make
71+
writing files deterministic.
72+
73+
- A header appears at the beginning and consists of the following:
74+
* A 4-byte mapping signature: `LMAP`
75+
* 4-byte version number: 1
76+
* 4-byte length of the header section (including reserved entries but
77+
excluding any NUL padding).
78+
* 4-byte number of objects declared in this map file.
79+
* 4-byte number of object formats declared in this map file.
80+
* For each object format:
81+
** 4-byte format identifier (e.g., `sha1` for SHA-1)
82+
** 4-byte length in bytes of shortened object names (that is, prefixes of
83+
the full object names). This is the shortest possible length needed to
84+
make names in the shortened object name table unambiguous.
85+
** 8-byte integer, recording where tables relating to this format
86+
are stored in this index file, as an offset from the beginning.
87+
* 8-byte offset to the trailer from the beginning of this file.
88+
* The remainder of the header section is reserved for future use.
89+
Readers must ignore unrecognized data here.
90+
- Zero or more NUL bytes. These are used to improve the alignment of the
91+
4-byte quantities below.
92+
- Tables for the first object format:
93+
* A sorted table of shortened object names. These are prefixes of the names
94+
of all objects in this file, packed together to reduce the cache footprint
95+
of the binary search for a specific object name.
96+
* A sorted table of full object names.
97+
* A table of 4-byte metadata values.
98+
- Zero or more NUL bytes.
99+
- Tables for subsequent object formats:
100+
* A sorted table of shortened object names. These are prefixes of the names
101+
of all objects in this file, packed together without offset values to
102+
reduce the cache footprint of the binary search for a specific object name.
103+
* A table of full object names in the order specified by the first object format.
104+
* A table of 4-byte values mapping object name order to the order of the
105+
first object format. For an object in the table of sorted shortened object
106+
names, the value at the corresponding index in this table is the index in
107+
the previous table for that same object.
108+
* Zero or more NUL bytes.
109+
- The trailer consists of the following:
110+
* Hash checksum of all of the above using the main hash.
111+
112+
The lower six bits of each metadata table contain a type field indicating the
113+
reason that this object is stored:
114+
115+
0::
116+
Reserved.
117+
1::
118+
This object is stored as a loose object in the repository.
119+
2::
120+
This object is a shallow entry. The mapping refers to a shallow value
121+
returned by a remote server.
122+
3::
123+
This object is a submodule entry. The mapping refers to the commit stored
124+
representing a submodule.
125+
126+
Other data may be stored in this field in the future. Bits that are not used
127+
must be zero.
128+
51129
GIT
52130
---
53131
Part of the linkgit:git[1] suite

Makefile

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1530,6 +1530,7 @@ UNIT_TEST_OBJS += $(UNIT_TEST_DIR)/test-lib.o
15301530

15311531
RUST_SOURCES += src/hash.rs
15321532
RUST_SOURCES += src/lib.rs
1533+
RUST_SOURCES += src/loose.rs
15331534
RUST_SOURCES += src/varint.rs
15341535

15351536
GIT-VERSION-FILE: FORCE

src/lib.rs

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,3 @@
11
pub mod hash;
2+
pub mod loose;
23
pub mod varint;

0 commit comments

Comments
 (0)