While we only support initializing repositories with the "files"
reference backend right now, we are in the process of implementing a
second backend with the "reftable" format. And while we already have the
infrastructure to decide which format a repository should use when we
open it, we do not have infrastructure yet to create new repositories
with a different reference format.
Introduce a new field `git_repository_init_options::refdb_type`. If
unset, we'll default to the "files" backend. Otherwise though, if set to
a valid `git_refdb_t`, we will use that new format to initialize the
repostiory.
Note that for now the only thing we do is to write the "refStorage"
extension accordingly. What we explicitly don't yet do is to also handle
the backend-specific logic to initialize the refdb on disk. This will be
implemented in subsequent commits.
To support multiple different reference backend implementations,
Git introduced a "refStorage" extension that stores the reference
storage format a Git client should try to use.
Wire up the logic to read this new extension when we open a repository
from disk. For now, only the "files" backend is supported by us. When
trying to open a repository that has a refstorage format that we don't
understand we now error out.
There are two functions that create a new repository that doesn't really
have references. While those are mostly non-functional when it comes to
references, we do expect that you can access the refdb, even if it's not
yielding any refs. For now we mark those to use the "files" backend, so
that the status quo is retained. Eventually though it might not be the
worst idea to introduce an explicit "in-memory" reference database. But
that is outside the scope of this patch series.
When we read the repository format information we do so by using the
full configuration of that repository. This configuration not only
includes the repository-level configuration though, but it also includes
the global- and system-level configuration. These configurations should
in practice never contain information about which format a specific
repository uses.
Despite this obvious conceptual error there's also a more subtle issue:
reading the full configuration may require us to evaluate conditional
includes. Those conditional includes may themselves require that the
repository format is already populated though. This is for example the
case with the "onbranch" condition: we need to populate the refdb to
evaluate that condition, but to populate the refdb we need to first know
about the repository format.
Fix this by using the repository-level configuration, only, to determine
the repository's format.
With a recent upgrade to a newer version of MSVC we now get a bunch of
warnings when two operands use different enum types. While sensible in
theory, in practice we have a couple of non-public enums that extend
public enums, like for example with `GIT_SUBMODULE_STATUS`.
Let's for now disable this warning to unblock our builds. The
alternative would be to add casts all over the place, but that feels
rather cumbersome.
Currently, the DefaultCFlags.cmake overrides the
CMAKE_STATIC_LINKER_FLAGS to suppress linker warnings about files with
no symbols defined.
This has the side effect of breaking MSVC cross compilation (where
CMAKE_STATIC_LINKER_FLAGS is used to specify the /MACHINE:ARCH flag)
This commit make sure we append to CMAKE_STATIC_LINKER_FLAGS instead of
replacing its values
src\libgit2\transports\auth_negotiate.h redefines git_http_auth_negotiate as git_http_auth_dummy if GIT_AUTH_NEGOTIATE is not defined, which thus leads to the uncommented code actually being a redifintion of git_http_auth_dummy. The linker complained [Windows 11, MSVC 2022 64bit].
I'm seeing the current fuzzer build fail (during `cmake`) like so:
```
-- Performing Test IS_FSANITIZE_FUZZER_NO_LINK_SUPPORTED
-- Performing Test IS_FSANITIZE_FUZZER_NO_LINK_SUPPORTED - Failed
CMake Error at cmake/AddCFlagIfSupported.cmake:17 (message):
Required flag -fsanitize=fuzzer-no-link is not supported
Call Stack (most recent call first):
fuzzers/CMakeLists.txt:6 (add_c_flag)
```
The cmake log output contains something like so:
```
/src/aflplusplus/libAFLDriver.a(aflpp_driver.o): in function `main':
aflpp_driver.c:(.text+0x11b): undefined reference to `LLVMFuzzerTestOneInput'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
I haven't figured out exactly what's happening, but I believe that
once line 5 has added `-fsanitize=fuzzer` to `CFLAGS`, future compile-
tests **also** use it during linking. This in turn pulls in the fuzzer
`main`, which expects an `LLVMFuzzerTestOneInput` symbol, and thus
fails.
Instead, just add `-fsanitize=fuzzer-no-link` to CFLAGS (as suggested
[by the documentation][libfuzzer]), and then use `-fsanitize=fuzzer`
only for linking the fuzzer targets. At least in my environment, this
results in a working fuzzer build.
[libfuzzer]: https://llvm.org/docs/LibFuzzer.html#fuzzer-usage
Some benchmarks require administrative privileges, namely the ones that
blow up the disk cache. Don't run them by default, to avoid obnoxious
sudo password prompts, etc. Users can specify `--admin` to run them.
The default in the world is to have a disk cache; it's exceptional to
_not_. Flip our naming, so that the (exceptional) `nocache` tests are
called out explicitly.
