Re: [PATCH 1/2] refs/reftable: don't fail empty transactions in repo without HEAD

From: Justin Tobler <jltobler@gmail.com>
Date: Mar 1, 2024, 01:20 UTC
Message-ID: <xcbwno3x7tzcg77rtfkaqtqcgll32vhx5mlhcvlclew6lkkofu@h5jzvft55uvv>
In-Reply-To: <95be968e10bd02c64448786e690bbefe5c082577.1709041721.git.ps@pks.im>

On 24/02/27 03:27PM, Patrick Steinhardt wrote:

Show 16 quoted lines

> Under normal circumstances, it shouldn't ever happen that a repository
> has no HEAD reference. In fact, git-update-ref(1) would fail any request
> to delete the HEAD reference, and a newly initialized repository always
> pre-creates it, too.
> 
> But in the next commit, we are going to change git-clone(1) to partially
> initialize the refdb just up to the point where remote helpers can find
> the repository. With that change, we are going to run into a situation
> where repositories have no refs at all.
> 
> Now there is a very particular edge case in this situation: when
> preparing an empty ref transacton, we end up returning whatever value
> `read_ref_without_reload()` returned to the caller. Under normal
> conditions this would be fine: "HEAD" should usually exist, and thus the
> function would return `0`. But if "HEAD" doesn't exist, the function
> returns a positive value which we end up returning to the caller.

In what context are reference transactions being created before the refdb is fully initialized? Is this in regards to repositories initialized with the reftables backend and used during execution of a remote-helper? I was originally under the impression that a partially initalized refdb would appear as the reffile backend before being fully initialized.

> 
> Fix this bug by resetting the return code to `0` and add a test.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>

-Justin