Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxx/ > https://lore.kernel.org/git/cover-v10-0.8-00000000000-20210823T114712Z-avarab@xxxxxxxxx/ > > For Han-Wen's v3 of this see: > https://lore.kernel.org/git/pull.1054.v3.git.git.1629207607.gitgitgadget@xxxxxxxxx/ > > 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@xxxxxxxxxxxxxxxxxxx/ > (summarized in > https://lore.kernel.org/git/87y28sfokk.fsf@xxxxxxxxxxxxxxxxxxx/) 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.
