Subject: Re: [PATCH v2 05/13] reftable: utility functions

From: Junio C Hamano <[email-masked]>
Date: Fri, 23 Oct 2020 10:36:26 -0700

Ævar Arnfjörð Bjarmason <[email-masked]> writes:

> It's not just about the number of lines, but things coming up in grep,
> and now unique code really stands out (e.g. strbuf_add_void, should
> probably be just added to the main strbuf.h if it's needed...), and of
> course the cost of attention of eyeballing an already big series on the
> ML & the churn every time we have updates.

These are all valid concerns.

> Overall I'm all for having this carved out in its own directory at a
> cost of a bit more maintenance burden if it can be shared with libgit2 &
> be a standalone library.

Do you mean by "this" the reftable stuff as a whole, or only the
duplicated support library part?  If the latter is split out of what
we import as our reftable/ directory, and stored in a separate
directory that we do not have to import (because we have strbuf and
other stuff) but other people may choose to use (because they may
not have strbuf and other stuff), that may work.  Also, if the
contents of reftable/ directory wants a pluggable allocator, the
main code can be written to call reftable_malloc (or whatever), with
a thin shim to interface with us (i.e. reftable_malloc() would be
implemented as a thin wrapper around xmalloc() for us) which is
stored in a separate directory just for us to interface with the
main reftable library.  For libgit2, there will be a separate
directory that uses a different implementation of reftable_malloc()
that would let them plug their preferred allocator.  An arrangement
like that might work.

I do not offhand know if that kind of overhead is worth the trouble
or if there are better ways, though.

> I am concerned that it seems this code can't be maintained in git.git by
> anyone not willing to sign a contract with Google.

It can be maintained in git.git; the trouble comes when they want to
update us.

I however suspect that, as the primary intended audience, it is hard
to imagine that the reftable library as a standalone project will be
successful without going through the usual reviews and testing in
git.git.  So even though there exists github.com/google/reftable
repository, its contents may not matter very much in practice,
unless they come here and beg for the change we make ourselves
anyway.  Perhaps I am being naive.  I dunno.

> I sent a tiny PR for
> a typo fix at [1] and got directed to sign [2] before someone at Google
> could look at it. I see brian raised this before in [3] but there wasn't
> a reply to that point.
>
> Is there some summary of how this part of integrating it is supposed to
> work going forward?

Yeah, thanks for raising a good point.  We definitely need to figure
this part out.

> At first glance that seems like a recipe for perma-forking this pretty
> much from day one, i.e.:
>
>  A. Upstream changes happen
>  B. We get a patch to the bundled library to this ML
>  ==> Google employees maintaining A can't even look at B
>  ==> Patch B can't be integrated into A
>
> 1. https://github.com/google/reftable/pull/2
> 2. https://cla.developers.google.com/about/google-individual
> 3. https://lore.kernel.org/git/[email-masked]/