On Mon, Jan 27, 2025 at 09:44:24AM -0800, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > > This patch series stops using all kinds of helpers exposed by our > > "git-compat-util.h" header and open-codes them instead. In order to keep > > us from using these helpers by accident the final step is to pull out > > POSIX-related bits and pieces into a new "compat/posix.h" header, which > > the reftable library then uses instead of "git-compat-util.h". > > Very nice. > > Is there something we can also do in order to keep reftable from using > stale version of these helpers that it copied with this series when > we make improvements on our side to the original? Overall the amount of duplication is quite limited. It looks like a lot in this patch series, but many of the changes are really only a couple of lines of code that are quite unlikely to grow stale. The subsystems that really are complex (think tempfiles, lockfiles) use the same underlying implementation as Git does via shims in "reftable/system.c". My hope is that by starting to use the reftable library in libgit2 we'll get additional test coverage thereof that helps weed out any issues we have, including issues in the compatibility layer. But I also assume that almost all bugs that we'll find will not be in the low-level code, but rather in the business logic of reftables themselves. > I think the answer might be "then use a common library > implementation that is used by both Git and reftable", but then we > might be in the same place as before? I dunno. I don't really have a good idea for how to do this. Using a common library would likely push us into the same place as before indeed, unless we started to split out standalone files that aren't allowed to link against anything but the "compat/" directory. But even if we had that it would be quite painful to take the reftable library and reuse it somewhere else, because now it's more than just "cp -r reftable/" and reimplementing system-specific bits in "reftable/system.c". I guess time will tell how much of a problem this really is. As said, my prediction is that we won't face many bugs in the low-level code, and then the question becomes moot anyway. But if time proves me wrong I'll think a bit more about potential solutions. Patrick
