On Wed, Jul 24, 2024 at 09:17:55AM +0200, Christian Couder wrote:
> On Wed, Jul 24, 2024 at 7:12 AM Chandra Pratap
> <chandrapratap3519@xxxxxxxxx> wrote:
> > On Tue, 23 Jul 2024 at 22:39, Junio C Hamano <gitster@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
