Re: [PATCH] object-file: reprepare alternates when necessary

From: Derrick Stolee <derrickstolee@github.com>
Date: Mar 8, 2023, 17:13 UTC
Message-ID: <87ecf011-415f-20d8-e781-18b97bfdca44@github.com>
In-Reply-To: <ZAiv2I17+/IBF8pl@nand.local>

On 3/8/2023 10:55 AM, Taylor Blau wrote:

> On Tue, Mar 07, 2023 at 09:52:19AM -0500, Derrick Stolee wrote:

Show 12 quoted lines

>> The prepare_alt_odb() call only _adds_ to the linked odb list. It
>> will not remove any existing ODBs. Adding this reprepare_*() method
>> makes it such that we can use the union of the alternates available
>> across the lifetime of the process.
> 
> Right, that matches my understanding. What I am asking is: since we only
> add ODBs to the list, what happens if we can no longer access an
> *existing* alternate at the time we call reprepare_alt_odb()?
> 
> It's clear that that now-inaccessible alternate remains in our list of
> alternate ODBs, but do all object lookups hitting that ODB fail-over to
> the new ODB? I believe so, but it isn't totally clear to me.

It's the same as the pack-file list: if we fail to load something from one, then we continue to the next one. If an alternate dir is completely removed during the process, then looking for pack- files again will fail to see any and continue without error.

This is already possible by deleting an alternate directory while a Git process is running and might try to open files in it. Git already recovers from this scenario.

If you're instead talking about the .git/objects/info/alternates file being modified to remove an alternate from the list, then Git's current behavior is to keep that alternate around for the life of the process, and I recommend continuing that behavior.

There's nothing special that we are adding here that doesn't already exist as protections when files are removed beneath the Git process.

Thanks, -Stolee