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

From: Derrick Stolee <stolee@gmail.com>
Date: Aug 24, 2026, 14:45 UTC
Message-ID: <ebaae70f-9e21-4673-b051-09e30420631e@gmail.com>
In-Reply-To: <5792c08f4ee0f9627ab1432d91299fe676e0a2f5.1787092446.git.gitgitgadget@gmail.com>

On 8/18/2026 6:34 PM, Elijah Newren via GitGitGadget wrote:

Show 8 quoted lines

> 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