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.
Introduce `--profile` support to the benchmark helper script, which will
invoke `perf` on Linux. Additionally, add a `--flamegraph` output
option based on that.
There's no such thing as a "loose object type" or a "packed object
type". There are only object types. Introduce `type_is_valid` and
deprecate `typeisloose`.
Compiling libssh2 into libgit2 directly is madness. If users want to
create a single library that contains libssh2, then they should link a
static library.
Introduce `git_oid_from_string`, `git_oid_from_prefix`, and
`git_oid_from_raw`, all of which take a `git_oid_t` that indicates what
type of OID should be parsed (SHA1 or SHA256).
This allows users to continue to use `git_oid_fromstr` without any code
changes, while remaining in a SHA1 world.
Note that these are not perfect analogs to the `fromstr` APIs.
* `git_oid_from_string` now takes a NUL terminated string, instead of
allowing for non-NUL terminated strings. Adding a NUL check feels like
an important safety consideration for C strings.
* `git_oid_from_prefix` should be used for an OID substring and length.
Previous usages of `git_oid_fromstr` with non-NUL terminated strings
should move to `git_oid_from_prefix` with the hexsize for the given OID
type.
There are several places where users may want to specify the type of
object IDs (sha1 or sha256) that should be used, for example, when
dealing with repositories, indexes, etc.
However, given that sha256 support remains disappointingly uncommon in
the wild, we should avoid hard API breaks when possible. Instead, update
these APIs to have an "extended" format (eg, `git_odb_open_ext`) that
provides an options structure with oid type information.
This allows callers who do care about sha256 to use it, and callers who
do not to avoid gratuitous API breakage.
It's hard to remember whether it's `-DUSE_HTTPS=mbedTLS` or
`-DUSE_HTTPS=mbedtls`. Even worse for things like `builtin` which we may
have been inconsistent about. Allow for case insensitive options.
There were a few oddities around HTTPS provider selection: namely,
`GIT_OPENSSL_DYNAMIC` implied `GIT_OPENSSL`, which made a bit of sense,
until we added FIPS support. In addition, dynamic OpenSSL for _hashes_
and dynamic OpenSSL for HTTPS was conflated in a few places.
Untangle these, and make `GIT_HTTPS_*` the define, for consistency with
other feature provider selection.
