Repository navigation
reftable support for libgit2 #5352
Description
See also #4981 (comment)
I have written a mostly complete implementation of reftable as a standalone library that depends only on zlib.
It is here: https://github.com/google/reftable (subdirectory c/ for the C code).
I have some alpha-quality code that integrates it into git-core, and am currently discussing how to proceed, both with the git-core team and the open-source lawyers at Google. I had intended this library to also be used in libgit2.
There are a couple of questions:
-
Do you want this in libgit2 as well (I think so, given the earlier comment)
-
How can we structure this? We could keep reftable as a standalone-separate library, or it can be integrated into some other project (eg. libgit2). If it is in libgit2, could patches move from libgit2 to git-core, license-wise? If we keep it as a separate library, do you see licensing problems with leaving the library under Apache2?
Activity
ethomson commentedon Jan 9, 2020
I do want this in libgit2 as well. 😁
My gut suggests that this is a standalone library and libgit2 and git both pull it in... probably by us pulling it in to our
depsfolder...? This might be the easiest way to allow git and libgit2 to collaborate on it?But what I really want to avoid is it going off in three different directions - the original, the libgit2 version and the git version. It would be nice if we had buy in from git that they would also consume the upstream and contribute back changes.
(Right now we're in a place where we have different xdiff implementations, which is sad.)
hanwen commentedon Jan 10, 2020
that is great to hear! I agree that there should be just one code base.
I was thinking that a standalone library would be overkill, as it would basically only be used by libgit2 and git-core, but maybe it is the most practical mechanism to allow cooperation.
Is libgit2 ok with linking to an Apache2 library?
hanwen commentedon Jan 10, 2020
For clarification, I think it is best to link the library statically into the either project, or even, to consume the library as a submodule (ie. compiling it directly into libgit2/cgit). I'd rather not have to deal with runtime .so versioning
hanwen commentedon Jan 10, 2020
IIUC, we can change license to be something else, but want to avoid dual licensing.
hanwen commentedon Jan 10, 2020
"probably by us pulling it in to our deps folder...?"
yes, that sounds perfect.
pks-t commentedon Jan 10, 2020
Fine with us, we're statically linking against all bundled dependencies anyway.
Unfortunately, no, as libgit2 uses GPLv2. Quoting the licenses page on gnu.org:
Note that the same applies to the git project, as they're using GPLv2 as well.
hanwen commentedon Jan 20, 2020
How is BSD 3-clause for you? https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD claims it is GPL compatible.
pks-t commentedon Jan 21, 2020
hanwen commentedon Jan 22, 2020
I changed the license in google/reftable@4e1cc9b
Can you have a look at the API to see if this works for you? It's over here:
https://github.com/google/reftable/blob/master/c/reftable.h
I wonder if I should prefix the type and function names with reftable_ to avoid namespace clashes.
Also, I wrote this for posix. It may need some tweaking to use with Windows. It'd be great to get patches for that, as I don't actually have any windows machine.
lorenzleutgeb commentedon May 13, 2024
Since reftables made it into Git 2.45, this might change the priority of adding support in libgit2?
lorenzleutgeb commentedon Sep 20, 2024
See #5462
groutoutlook commentedon Sep 8, 2025
hi, have
git2get any traction on support forreftableyet? Newly clone repo is broken forextension.refstorage, even dotnet build is broken withoutgit config --global --unset-all extensions.refstorageAdditional Context
pks-gitlab commentedon Sep 8, 2025
@groutoutlook There's a fully working backend in #7117. Only problem is that we're lacking reviewers, and because of that it cannot be merged. If you want to help moving it along you can do so by reviewing that pull request and its dependencies.
rjorgenson commentedon May 11, 2026
I see this PR was merged 5 days ago(🙌 ), is this going to part of the v2 release coming up or will there be another release prior to that sooner?
simnalamburt commentedon Jun 8, 2026
Context for visitors: PR #7117 was merged to main branch, but it was not included in the v1.9.3 or v1.9.4 releases.
ofek commentedon Jul 1, 2026
The release notes for v1.9.0 indicate that the next feature release will likely be a major version bump that will introduce backward-incompatible changes. Since the note says that it's "expected" to be the last v1.x rather than something set in stone, would it be possible to have a v1.10.x so that folks can start using #7117 and other features?
Alternatively, are there any remaining blockers for releasing v2.0.0? The expected breaking changes don't appear to be that disruptive, all things considered.
cc @ethomson @carlosmn
Freed-Wu commentedon Jul 11, 2026
Some downstreams are waiting this feature:
simnalamburt commentedon Jul 13, 2026
In fact, the
libgit2main branch (HEAD) is quite stable. Everything works well enough that you can just use the main branch without waiting for a new release. I've been using it more than a month and there was no issue. :)Reference: romkatv/gitstatus#455 (comment)