Re: [PATCH v2 00/10] reftable: stop using `struct strbuf`

> > I have read some patches yesterday, I feel quite strange that we need to
> > make repetition. Could we provide a header file which requires the users
> > who need to use the reftable library to implement the interfaces?
> > 
> >     reftable_strbuf_addf(void *buf, char *fmt, va_list ap);
> > 
> > Thus, we could reuse "strbuf_addf" to implement this interface in Git.
> > As for libgit2, could we let it implement these interfaces? Although I
> > have never read the source code of libgit2, I think there should be some
> > code which could be reuse to implement these interfaces?
> > 
> > However, I do not know the context. Maybe the above is totally wrong. If
> > so, please ignore.
> 
> The thing is that we'll have repetition regardless of what we end up
> doing:
> 
>   - We could either have repetition once in the reftable library,
>     reimplementing `struct strbuf`. This can then be reused by every
>     single user of the reftable library.
> 
>   - Or we can have repetition for every single user of the reftable
>     library. For now that'd only be Git and libgit2, but we'd still have
>     repetition.
> 
> The second kind of repetition is way worse though, because now every
> user of the reftable library has a different implementation of a type
> that is as basic as a buffer. These _must_ behave the exact same across
> implementations or we will hit issues. So I'd rather have the repetition
> a single time in the reftable library such that all users of the library
> will behave the same rather than having downstream users copy the
> implementation of `struct strbuf` and making it work for their library.
> 

> Also, due to the nature of `struct strbuf` not allowing for allocation
> failures we'd already have diverging behaviour. In Git you would never
> hit error code paths for allocation failures, whereas every library user
> potentially can.
> 
> So we really have to treat the reftable code base special. If we want to
> be a good citizen and be a proper upstream for projects like libgit2 we
> don't really have much of a choice than to detangle it from libgit.a. If
> we don't we may be saving 20 lines of code, but we make everybody elses
> life harder.
>