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

>
> 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.