Subject: Re: [PATCH v4 00/28] Support reftable ref backend for Git

From: Junio C Hamano <[email-masked]>
Date: Thu, 26 Aug 2021 01:39:46 -0700

Ævar Arnfjörð Bjarmason  <[email-masked]> writes:

> This is a version of the reftable series queued on top of my
> just-re-rolled fixes to the refs APIs, which it can make use of. For
> the base topics see:
>
>     https://lore.kernel.org/git/[email-masked]/
>     https://lore.kernel.org/git/[email-masked]/
>
> For Han-Wen's v3 of this see:
> https://lore.kernel.org/git/[email-masked]/
>
> I've got no desire to take over the reftable topic in its entirety,
> but think given the rationale in
> https://lore.kernel.org/git/[email-masked]/
> (summarized in
> https://lore.kernel.org/git/[email-masked]/) that
> having the refs API fixes I noted above wait on the still-unstable
> reftable doesn't make sense.

Of course, you and Han-Wen are in much better position to judge the
relative merit to decide which one should go first than I am, but I
had an impression that the errno thing was even less stable, with
API churn that deliberately broke the other topic in flight, which
appeared to be just irresponsible.

> I'll let Han-Wen deal with that squashing in a presumed future v5 of
> this, assuming of course that Junio's happy with the plan of basing
> hn/reftable on the refs API fixes above.
>
> I'm not sure that the fix I have in 27/28 is the right one, perhaps
> we've already got information about what the tip OID of the refname is
> at that point in git_reftable_reflog_expire() via some API I missed,
> but that fix works, and is clearly more correct than the outstanding
> segfault.