Patrick Steinhardt <ps@xxxxxx> writes: > We have two different functions to retrieve packfiles for a packfile > store: > > - `get_packed_git()` returns the list of packfiles directly. > > - `get_all_packs()` does more work and also prepares packfiles that > are being indexed by a multi-pack-index. > Question, under what situation would a packfile not returned by `get_packed_git()` but be indexed by a multi-pack-index. > The distinction is not immediately obvious. Furthermore, to make the > situation even worse, `get_packed_git()` would return the same result as > `get_all_packs()` once the latter has been called once as they both > refer to the same list. > > As it turns out, the distinction isn't necessary. We only have a couple > of callers of `get_packed_git()`, and all of those callers are prepared > to call `get_all_packs()` instead: > > - "builtin/gc.c": We explicitly check how many packfiles aren't > contained in the multi-pack-index, so loading extra packfiles that > are indexed by it won't change the result. > > - "builtin/grep.c": We only care `get_packed_git()` to prepare eagerly > load packfiles. In the preceding commit we have started to expose Nit: the first sentence reads a bit weird. > `packfile_store_prepare()`, which is a more direct way of achieving > the same result. > > - "object-name.c": `find_abbrev_len_for_pack()` and `unique_in_pack()` > exit early in case the multi-pack index is set, so both callsites of > `get_packed_git()` know to handle packs loaded via the MIDX already. > > Convert all of these sites to use `get_all_packs()` instead and remove > `get_packed_git()`. > [snip]
Attachment:
signature.asc
Description: PGP signature
