Skip to content

Commit 4a9179d

Browse files
ttaylorrgitster
authored andcommitted
Documentation: remove a "future work" item from the MIDX docs
One of the items listed as "future work" in the MIDX's technical documentation is to extend the format to allow MIDXs to be written incrementally across multiple layers. This was suggested all the way back in ceab693 (multi-pack-index: add design document, 2018-07-12), and implemented in b949784 (Merge branch 'tb/incremental-midx-part-1', 2024-08-19). Let's remove it accordingly. Signed-off-by: Taylor Blau <[email protected]> Acked-by: Elijah Newren <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 683c54c commit 4a9179d

File tree

1 file changed

+0
-10
lines changed

1 file changed

+0
-10
lines changed

Documentation/technical/multi-pack-index.adoc

Lines changed: 0 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -167,16 +167,6 @@ m->num_objects_in_base`).
167167
Future Work
168168
-----------
169169
170-
- The multi-pack-index allows many packfiles, especially in a context
171-
where repacking is expensive (such as a very large repo), or
172-
unexpected maintenance time is unacceptable (such as a high-demand
173-
build machine). However, the multi-pack-index needs to be rewritten
174-
in full every time. We can extend the format to be incremental, so
175-
writes are fast. By storing a small "tip" multi-pack-index that
176-
points to large "base" MIDX files, we can keep writes fast while
177-
still reducing the number of binary searches required for object
178-
lookups.
179-
180170
- If the multi-pack-index is extended to store a "stable object order"
181171
(a function Order(hash) = integer that is constant for a given hash,
182172
even as the multi-pack-index is updated) then MIDX bitmaps could be

0 commit comments

Comments
 (0)