From: Elijah Newren Date: Tue, 25 Aug 2026 07:38:12 GMT Subject: Re: [PATCH 2/2] packfile: recover when a multi-pack-index names a removed pack Message-ID: In-Reply-To: On Mon, Aug 24, 2026 at 7:45 AM Derrick Stolee wrote: > > On 8/18/2026 6:34 PM, Elijah Newren via GitGitGadget wrote: > > From: Elijah Newren > > > > 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. Oh, good pointer. It may make sense to teach geometric repacking about "git multi-pack-index expire", which I think would be complementary and reduce how often we fall into recovery, while the changes in this patch help keep us correct when we do fall into recovery.