Re: Concurrent fetch commands

From: Taylor Blau <me@ttaylorr.com>
Date: Jan 3, 2024, 16:40 UTC
Message-ID: <ZZWOBObBmLW9Nid6@nand.local>
In-Reply-To: <ZZU5s4LKQF1NLgnC@tanuki>

On Wed, Jan 03, 2024 at 11:40:51AM +0100, Patrick Steinhardt wrote:

Show 7 quoted lines

>   - `--append` should handle concurrency just fine, that is it knows to
>     append to a preexisting lockfile. This is messy though, and the
>     original creator of the lockfile wouldn't know when it can commit it
>     into place.
>
> Both options are kind of ugly, so I'm less sure now whether lockfiles
> are the way to go.

Interesting. Thinking a little bit about what you wrote here, I feel like `--append[=<FETCH_HEAD>] would do what you need here. The creator of the lockfile would commit it into place exactly when all children have finished writing into the existing lockfile.

It seems like that could work, but I haven't poked around to figure out whether or not that is the case. Regardless, supposing that it does work, I wonder what users reasonably expect in the presence of multiple 'git fetch' operations. I suppose the answer is that they expect concurrent fetches to be tolerated, but that the contents of FETCH_HEAD (and of course the remote references) are consistent at the end of all of the fetches.

Thanks, Taylor