Update our headers so that they can include the necessary definitions.
Docs generators (in particular, `clang -Xclang -ast-dump`) were unable
to see the necessary definitions.
Users can now override the "product" portion of the user-agent (via
GIT_OPT_SET_USER_AGENT_PRODUCT). This continues to default to "git/2.0",
but users may define their own string, or may opt out of sending a
user-agent entirely (by passing an empty string). Similarly, users may
now also opt-out of sending any additional "comment" information by
setting the GIT_OPT_SET_USER_AGENT value to an empty string.
Update the nightly and benchmark workflows to only run steps in
libgit2/libgit2 by default. Also update the benchmark workflow to use
the latest download-artifact version.
Split the SHA256 builds into their own workflow; since they're
experimental (and have proven to be flaky) they shouldn't be used as
signal that there's a problem with a PR.
The Microsoft C runtime (MSVCRT) may take a heavy lock on the
locale in order to figure out how the `ctype` functions work.
This is deeply slow. Provide our own to avoid that.
On POSIX, provide emulation for that functionality using the ctype
functions, but compress the return value into a `bool`, and cast the
value to an `unsigned char`.
Update `git_fetch_options` to break out the fetch options into
individual options. This prevents creating an API breaking change from
v1.7.0. `git_remote_update_tips` retains the `update_flags` to also
avoid an API breaking change.
Instead of trying to allocate something, hand it to mbedTLS, and then
peer into its private data structures to try to free that thing... we
could just keep track of it ourselves.
Once we've done that, we needn't do an allocation _anyway_, we can just
keep it on the stack.
libgit2 may adjust the system includes - for example, to locate a
dependency installed in a funny location. Ensure that the cli
understands those include paths as well.
The packbuilder tests should be deterministic. This comment suggests
that they are:
```
/*
* By default, packfiles are created with only one thread.
* Therefore we can predict the object ordering and make sure
* we create exactly the same pack as git.git does when *not*
* reusing existing deltas (as libgit2).
*
* $ cd tests/resources/testrepo.git
* $ git rev-list --objects HEAD | \
* git pack-objects -q --no-reuse-delta --threads=1 pack
* $ sha1sum pack-7f5fa362c664d68ba7221259be1cbd187434b2f0.pack
* 5d410bdf97cf896f9007681b92868471d636954b
*
*/
```
but it is disappointingly incorrect. As is evidenced by the fact that --
at least on _my_ machine -- that command does not actually produce that
output any longer.
Variations in things like the which compression library is actually
used, and its defaults, mean that we cannot accurately predict or
enforce the bytes in the packfile from one system to another.
Adjust the tests so that they do not believe that they should enforce
the bytes in the packfile. This allows broader compatibility with
zlib-compatible compression libraries, or other compression levels.
