Pseudoref lookup now reads `FETCH_HEAD` directly as a loose ref,
but callers still expect looked-up references to know their owning
repository.
Attach the repo's refdb after the loose pseudoref is read so
owner-dependent ops such as peeling can safely resolve objects.
b17ecb23e changed pseudoref lookup to read loose refs directly,
bypassing refdb lookup.
This documents the resulting buggy behavior:
a looked-up `FETCH_HEAD` pseudoref has no owning refdb attached.
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.
This would be useful for user to determine whether they want to proceed
or bail further remote operations. Particularily useful for downstream
libgit2 bindings and applications to experiment SHA256 support behind a
runtime feature flag.
For example, `cargo` could compile with sha256 support unconditionally,
but reject SHA256 usage at runtime if the `-Zgit=sha256` nightly flag
was not on. Cargo would leverage this new API to determine if users are
trying to fetch a SHA256 remote repository and bail when needed before
any fetches happen.
Note that this is not gated behind `GIT_EXPERIMENTAL_SHA256` as the
oid_type is sha1 and available always.
