Wire up reftable tests so that they can be executed by setting the
`CLAR_REF_FORMAT` environment variable. This only catches tests that use
`cl_git_sandbox_init()`, but that should cover most of our tests. So
this infrastructure isn't perfect, but for now it's good enough. We may
want to iterate on it in the future.
Generate test resources for reftables. These resources are basically the
Git repositories we already have, but converted to use the "reftable"
format. For most of the part, this conversion is done by executing `git
refs migrate`.
A couple notes:
- This require a recent Git upstream version with not-yet-upstreamed
patches due to a bug in `git refs migrate` with reflogs.
- The migration command does not yet support repositories with
worktrees. Those were converted by first removing the worktrees,
migrating the refs and then recreating them.
- The HEAD_TRACKER reference in testrepo.git is not recognized as a
root ref and is thus not automatically migrated.
- testrepo.git has an empty reflog for refs/heads/with-empty-log that
does not get migrated.
Extract the function `is_per_worktree_ref()` from the "files" backend
and expose it via "refs.h". This function will be reused by the
"reftable" backend.
While the reftable library is mostly decoupled from the Git codebase,
some specific functionality intentionally taps into Git subsystems. To
make porting of the reftable library easier all of these are contained
in "system.h" and "system.c".
Reimplement those compatibility shims so that they work for libgit2.
Import the reftable library from commit 4fee6ff3b2 (Merge branch
'ps/reftable-portability', 2026-04-08). This is an exact copy of the
reftable library.
The library will be wired into libgit2 over the next couple of commits.
In our util headers we expose the `GIT_INLINE()` macro to declare a
function as inline, but we don't provide a way to access the keyword
directly.
Expose a new `GIT_INLINE_KEYWORD` to fill this gap. This define will be
used in a subsequent commit.
We have a bunch of checks for properties of the "files" reference
backend:
- Whether a specific reference has been packed or whether it still
exists as a loose reference.
- Whether empty ref directories get pruned.
- Whether we properly fsync data to disk.
These checks continue to be sensible for that backend, but for any other
backend they plain don't work. Adapt the tests so that we only run them
in case the repository uses the "files" backend.
When testing conditional includes we overwrite the repository's config
file with the relevant conditions. This causes us to fully overwrite all
repository configuration, including the repository format version and
any extensions. While the test repository used in this test does not
have any extensions, we will add a reftable-enabled repository that does
rely on the "refStorage" extension eventually.
Fix this by only modifying the relevant config keys.
There are a bunch of tests where we read or write references via the
filesystem directly. This only works with the "files" backend, but
naturally breaks if we supported any other reference format.
Refactor these tests to instead use the refdb to access those.
Introduce a function that reads the "refStorage" extension so that we
can easily figure out whether a specific repository uses the "files" or
any other reference format. While we don't support other formats yet, we
are about to add support for the "reftable" format.
The fallback definition of O_FSYNC uses `(1 << 31)`, which is undefined
behavior in C. The literal `1` is a signed int, and left-shifting into
the sign bit of a signed integer is undefined per the C standard.
This causes crashes on arm64 Linux with musl libc (which doesn't define
O_FSYNC), manifesting as:
thread panic: left shift of 1 by 31 places cannot be represented
in type 'int'
Fall back to O_SYNC when available, since it is the POSIX standard name
for the same flag. On platforms where neither is defined (e.g. Windows),
use (1 << 30) as a sentinel value that avoids the sign bit.
We need this in order for `pkg-config` to be able to tell what you should link
against when building libgit2 statically. We do include libssh2 in
`Libs.private` but not in `Requires.private`. The difference is a bit subtle but
has become important.
You can call `pkg-config --libs --static ${build}/libgit2.pc` and it will give
you what is in the Libs line, and also what the packages from the Requires field
have in theirs. This is what e.g. `rugged` does and it has been working until
recently. An update to openssl to require zstd now means that using `--libs
--static` returns `-lzstd` as well as many others. This means that those who
want to link using that command now need to have the development packages for
zstd installed, which should not be necessary as libgit2 itself doesn't want to
use anything from it.
A better command to use here seems to be `pkg-config --libs --static --pure
${build}/libgit2.pc`. The manpage and help output are not very precise but what
this does is limit the list of dependencies to a single layer, which is what we
want as we would only want to link statically against libgit2 and not the rest
of the libraries.
But trying to do so breaks building with libssh2 as it's included in the Libs
field rather than the Requires, so that command excludes any linking to libssh2.
Put libssh2 in the `Requires.private` field so we correctly express we need to
link to it when linking statically.
This is unfortunately an imperfect fix as now, if we did not find libssh2 via
pkg-config but rather via CMake's `find_package`, the combination of `--static
--pure` does not take `Libs.private` into account. However we only support this
as an edge case and we expect `pkg-config` to be available for the rest of our
dependencies.
At present, the library's oid manipulation functions are slower when
built in SHA256 mode than when not. Add some microbenchmarks around the
oid compare and copy functions to understand this better.
If an error occurs when calling `git_revparse_single()` with
`revspec->to`, `revspec->from` must be freed, since it was already
successfully allocated.
