Re: [PATCH 2/2] packfile: recover when a multi-pack-index names a removed pack

[Derrick Stolee <stolee@gmail.com>]

On 8/18/2026 6:34 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> When a geometric repack runs concurrently with other git processes, it
> can write a new pack and multi-pack-index and then delete older packs
> that the new one subsumes.  One or more of those older packs may have
> been indexed by the previous multi-pack-index.  A process that already
> had the previous multi-pack-index open keeps using it, and that stale
> index still records the removed pack(s) as owning some objects.

This kind of race is why 'git multi-pack-index expire' exists, to
delete packfiles whose objects are all referenced within other
packfiles. The inclusion of these "stale" packs in the multi-pack-index
helps halt reads of those packfiles by new processes while allowing
them to be read by existing processes.

This is currently used in the incremental repacks done by 'git
multi-pack-index repack' and maybe could be used again in this kind
of geometric repack.

(This dance is more important on Windows platforms where read handles
prevent deletions, so it's common to have a foreground operation
prevent a packfile deletion in background maintenance.)

I do think your attempts to be more robust to missing packs is good,
but the comment thread does show that it's a complicated situation
that we may want to avoid whenever possible. Leaving some redundant
data around for some time interval can reduce the number of times
that the fallback logic is triggered.

Thanks,
-Stolee