On Mon, Sep 06 2021, Junio C Hamano wrote: > Han-Wen Nienhuys <hanwen@xxxxxxxxxx> writes: > >> On Fri, Sep 3, 2021 at 12:48 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> * hn/reftable (2021-08-26) 29 commits >>> - SQUASH??? https://github.com/git/git/runs/3439941236?check_suite_focus=true#step:5:700 >>> - reftable: fixup for new base topic 3/3 >>> - reftable: fixup for new base topic 2/3 >>> - reftable: fixup for new base topic 1/3 >> .. >>> The "reftable" backend for the refs API. >> >> I posted a subset of these patches as >> https://lore.kernel.org/git/pull.1081.git.git.1630335476.gitgitgadget@xxxxxxxxx/ > > Thanks for a ping. I saw it but haven't read it. > >> As discussed with AEvar, it will probably speed things up if we can >> focus on getting the base library submitted without hooking it up to >> Git. This would avoid cross-interactions with other pending topics, >> and reduce the size of the more controversial topic (hooking it up to >> Git). > > My worry is that a "base library" that is not hooked up to anything > that works in the system would not be properly reviewed at all. Of > course, without review, it would speed things up, but it is unclear > if that the kind of speed we want. > > Anyway, I'll eject the old topic and replace them with the latest > one soonish. The proposal is to still have it hooked up to t/helper/test-reftable.c, the build system, and t0032-reftable-unittest.sh. So we'd build and test it on all platforms, getting that working in some stable fashion would already be a big step forward. What we wouldn't get right away is the series as of things like 0a0d5fe74d4 (refs: RFC: Reftable support for git-core, 2021-08-17), i.e. hooking up refs/reftable-backend.c, changes to refs.[ch], running reftable with some mode of "git init". As discussed elsewhere that step would currently fail with some tests failing, but most/all of those failures are due to the integration of the reftable library into git, not failings of the library itself or the reftable format.
