hn/reftable (Re: What's cooking in git.git (Sep 2021, #08; Mon, 27))

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 28, 2021, 08:35 UTC
Message-ID: <871r59xfgk.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq8rzhmsi7.fsf@gitster.g>

On Mon, Sep 27 2021, Junio C Hamano wrote:

Show 26 quoted lines

> * 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@evledraar.gmail.com/