On Mon, Sep 27 2021, Junio C Hamano wrote: > * hn/reftable (2021-09-10) 20 commits > - fixup! reftable: implement stack, a mutable database of reftable files. > - Add "test-tool dump-reftable" command. > - reftable: add dump utility > - reftable: implement stack, a mutable database of reftable files. > - reftable: implement refname validation > - reftable: add merged table view > - reftable: add a heap-based priority queue for reftable records > - reftable: reftable file level tests > - reftable: read reftable files > - reftable: generic interface to tables > - reftable: write reftable files > - reftable: a generic binary tree implementation > - reftable: reading/writing blocks > - Provide zlib's uncompress2 from compat/zlib-compat.c > - reftable: (de)serialization for the polymorphic record type. > - reftable: add blocksource, an abstraction for random access reads > - reftable: utility functions > - reftable: add error related functionality > - reftable: RFC: add LICENSE > - hash.h: provide constants for the hash IDs > > The "reftable" backend for the refs API, without integrating into > the refs subsystem. > > Will merge to 'next'? I think we've reached approximately "good enough" with this for the next steps, and can hopefully fix any remaining nits (such as my [1]) post-merge. Maybe hold off until Han-Wen gets a chance to ack it, and whether he's ok with the proposed fixup(s)? Wasn't there an outstanding "some of this in reftable/* should be static functions" from someone, Carlo? (CC'd). In any case that sort of thing could also be a post-cleanup, I couldn't find a reference to that discussion in anything except my vague memory of it as I wrote this. 1. https://lore.kernel.org/git/87wnn62nhp.fsf@xxxxxxxxxxxxxxxxxxx/
