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@xxxxxx> > > -Justin
Attachment:
signature.asc
Description: PGP signature
