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

Ævar Arnfjörð Bjarmason  [off-list ref] 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/cover-v5-00.13-00000000000-20210823T113115Z-avarab@gmail.com/ (local)
    https://lore.kernel.org/git/cover-v10-0.8-00000000000-20210823T114712Z-avarab@gmail.com/ (local)

For Han-Wen's v3 of this see:
https://lore.kernel.org/git/pull.1054.v3.git.git.1629207607.gitgitgadget@gmail.com/ (local)

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/877dgch4rn.fsf@evledraar.gmail.com/ (local)
(summarized in
https://lore.kernel.org/git/87y28sfokk.fsf@evledraar.gmail.com/ (local)) 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.