On Thu, Feb 29, 2024 at 07:20:42PM -0600, Justin Tobler wrote:
> On 24/02/27 03:27PM, Patrick Steinhardt wrote:
> > 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.

The only case where this can happen is during git-clone(1).

Patrick

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