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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 28, 2021 at 10:38 AM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> 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.

There is still an RFC in 02/19. Maybe we can get agreement that this
is OK and drop the RFC ?

> Maybe hold off until Han-Wen gets a chance to ack it, and whether he's
> ok with the proposed fixup(s)?

regarding uncompress2: I thought it was functionality best left to
zlib to implement, but I imagine git.git offers something similar.
Sounds good to use that.

> 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.

I think I have addressed all outstanding issues in my github PR, and
I'll send it out once I see CI pass.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux