Re: [GSoC][PATCH v5 0/7] t: port reftable/pq_test.c to the unit testing framework

From: Patrick Steinhardt <ps@pks.im>
Date: Jul 24, 2024, 08:56 UTC
Message-ID: <ZqDBxUC34pV2TLGz@tanuki>
In-Reply-To: <CAP8UFD12Cqorr7oPS+JfOTYY6LaNUgPEJaEscf-jwLUOur+xqA@mail.gmail.com>

On Wed, Jul 24, 2024 at 09:17:55AM +0200, Christian Couder wrote:

Show 30 quoted lines

> On Wed, Jul 24, 2024 at 7:12 AM Chandra Pratap
> <chandrapratap3519@gmail.com> wrote:
> > On Tue, 23 Jul 2024 at 22:39, Junio C Hamano <gitster@pobox.com> wrote:
> > I did talk about this with Patrick and Christian on a private slack channel
> > a few weeks ago and here is how that conversation went:
> >
> > Me: Hey, I wanted to talk about the message from Junio the other day.
> > It is true that through this project, we are modifying the reftable directory
> > to a point that it is no longer easily usable by someone from outside. If
> > that is the direction we want to take, wouldn't it make more sense to get
> > rid of reftable/pq.{c, h} altogether and use Git's prio-queue instead?
> >
> > Christian: Yeah, I think the direction the Git project wants to take is to
> > integrate the reftable code more and more with the Git code. On the other
> > hand, there are libification projects which are trying to split parts of the
> > Git code into libraries usable by other projects. But I don't think each of
> > these libraries should have their own test framework, their own prio-queue
> > implementation, their own string implementation, etc. So, even if I am not
> > sure about the end result, I think it would be ok to modify the reftable code
> > so that it uses the Git's prio queue and maybe other Git data structures.
> > But I'd like Patrick to confirm, and the list to agree to this. So I'd
> > rather wait
> > until Patrick is back from his vacation before doing things like replacing
> > reftable/pq.{c, h} with Git's prio-queue.
> 
> Yeah, if it had been discussed and agreed on earlier, I think
> replacing the pq implementation would have made sense. Now I think
> it's a bit late at this stage in Chandra's GSoC to go in this
> direction though. I think it's better if he can focus on finishing to
> replace the unit test framework.

Replacing the priority queue with the one we already have will create additional work in the future when we want to get the reftable library back into a state where it can be used as a standalone library again. I know that it's currently a mess anyway, but I've heard from multiple folks already who are interested in using the reftable library in their own C projects (most importantly libgit2).

If we want Git to be the reftable upstream for such projects, then we should play nice and not make their lifes harder. I plan to work on portability work as soon as somebody properly commits to integrating reftables into their project. This will probably come in the form of:

  - Removing all Git-specific includes in the "reftable/" directory.

  - Declaring a list of "shim" functions and types that users of the
    reftable library need to use.

  - Implementing those shim functions for Git.

Of course, those shims will closely follow the interfaces that we have in Git. E.g. there will shims for "strbuf", the tempfile interface, and everything else that we currently use in the reftable library. So ultimately, I expect that the shim implementations will simply look like the following:

``` typedef struct strbuf reftable_buf;

static inline void reftable_buf_add(struct strbuf reftable_buf *buf,
                                    const void *data, size_t len)
{
    strbuf_add(buf, data, len);
}
```

While we could also shim out the priority queue, I don't really think that it is worth it.

Patrick