]> git.ipfire.org Git - thirdparty/git.git/commit
builtin/repack.c: inline packs within `write_midx_included_packs()`
authorTaylor Blau <me@ttaylorr.com>
Wed, 15 Oct 2025 22:29:10 +0000 (18:29 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 16 Oct 2025 17:08:56 +0000 (10:08 -0700)
commitf17757487b2d212f86edaaf02306972e1a555bbd
treed01b14df1ba94965d03f73ebd94d7f5672248513
parentf07263fd9fcb6b03f1e1db041269e2d5b85ccff8
builtin/repack.c: inline packs within `write_midx_included_packs()`

To write a MIDX at the end of a repack operation, 'git repack' presently
computes the set of packs to write into the MIDX, before invoking
`write_midx_included_packs()` with a `string_list` containing those
packs.

The logic for computing which packs are supposed to appear in the
resulting MIDX is within `midx_included_packs()`, where it is aware of
details like which cruft pack(s) were written/combined, if/how we did a
geometric repack, etc.

Computing this list ourselves before providing it to the sole function
to make use of that list `write_midx_included_packs()` is somewhat
awkward. In the future, repack will learn how to write incremental
MIDXs, which will use a very different pack selection routine.

Instead of doing something like:

    struct string_list included_packs = STRING_LIST_INIT_DUP;
    if (incremental) {
        midx_incremental_included_packs(&included_packs, ...):
        write_midx_incremental_included_packs(&included_packs, ...);
    } else {
        midx_included_packs(&included_packs, ...):
        write_midx_included_packs(&included_packs, ...);
    }

in the future, let's have each function that writes a MIDX be
responsible for itself computing the list of included packs. Inline the
declaration and initialization of `included_packs` into the
`write_midx_included_packs()` function itself, and repeat that pattern
in the future when we introduce new ways to write MIDXs.

Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/repack.c