Git does not limit relative paths in alternates to the first
repository, so libgit2 shouldn't either.

In v1.9, we failed to document that `update_refs` was a breaking change.
Add information about this change to the ABI breaking changes section.

GIT_ERROR_CHECK_ALLOC was added to check the return value of git__calloc().

libdir can be something else than /usr/lib, e.g. /usr/lib64 or similar.

The `fullpath` function takes the cli, but doesn't keep the cli.

I tried to build my libgit2-1.9.0 package for CYGWIN but I got an error. This message appears when compiling:

[199/671] Building C object src/cli/CMakeFiles/git2_cli.dir/opt.c.o
libgit2-1.9.0/src/cli/opt.c: In function ‘cli_opt_parse’:
libgit2-1.9.0/src/cli/opt.c:564:23: warning: implicit declaration of function ‘alloca’; did you mean ‘malloc’? [-Wimplicit-function-declaration]
  564 |         given_specs = alloca(sizeof(const cli_opt_spec *) * (args_len + 1));
      |                       ^~~~~~
      |                       malloc

and later the linker emits this error message:

[668/671] Linking C executable git2.exe
FAILED: git2.exe
/usr/x86_64-pc-cygwin/bin/ld: src/cli/CMakeFiles/git2_cli.dir/opt.c.o: in function `cli_opt_parse':
/usr/src/debug/libgit2-1.9.0-1/src/cli/opt.c:564:(.text+0xce3): undefined reference to `alloca'
collect2: error: ld returned 1 exit status

The error is fixed by adding alloca.h to included headers.
Hopefully, opt.c already allows to add alloca.h for some platforms, so I just added an additional test for the preprocessor for checking if the target is CYGWIN.

`.gitattributes` is case-insensitive when `core.ignorecase=true`.

Like we set temporary system and global configuration directories, we
need to set a programdata directory for safe test handling.

The filter tests mutate state, and should set a temporary sysdir to do
so.

Not all filesystems on Apple and Windows platforms are
case‐insensitive; this test would previously fail on a
case‐sensitive APFS volume.

Fixes #7027

Update to the latest version (in HEAD) of clar. This affords us improved
test directory creation, and the `cl_invoke` helper macro.

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

Sync with vanilla Git, cf. git/git@bbd445d5efd415

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Signed-off-by: Dominique Fuchs <32204802+DominiqueFuchs@users.noreply.github.com>

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