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.
This removes the phrase "if cert verification fails" because the
certificate callback is *always* called whether it fails or not. This
was changed in
17491f6e56,
but presumably this piece of documentation was not updated.
Update the library's (API) version number to v1.9.0. Also update the
soname version number to 2.0, since we've had breaking ABI changes
to the library.
By placing the X509 cert constant option in the middle of the existing
options, it renumbers everything unnecessarily. Move it to the end in
to avoid breaking changes.
Provide a mechanism to understand the backend provider for feature
within libgit2. For example, one can query the mechanism that provides
HTTPS by asking for the backend for the `GIT_FEATURE_HTTPS`.
This is particularly useful for features that are not completely
isomorphic; the HTTPS providers may have slightly different
functionality that can be controlled (eg, certificates or cipher
support). And the SSH feature is _very_ different between libssh2 and
OpenSSH.
It may also be useful to understand the support for things like the SHA1
or SHA256 backends to ensure that sha1dc is used, or that FIPS mode is
enabled.
Instead of making the commit and dump functions take individual options
structures; provide the options structure to the writer creator. This
allows us to add additional information (like OID type) during
generation.
Negative refspecs were added in Git v2.29.0 and are denoted by prefixing
a refspec with a caret. This adds a way to distinguish if a refspec is
negative and match negative refspecs.
The `git_reflog_entry__alloc` function is not actually defined, nor
used. Remove references to it in the headers. It is not clear why the
corresponding `__free` is, or should be, exported. Make it internal to
the library.
Instead of dealing with the clone options sub-options (fetch, checkout,
etc) individually, treat them as a cohesive whole when passing them
throughout the system.
Additionally, move some functions around within the file to avoid
unnecessary decls at the top of the file. And change a function
signature to avoid conflating truth with error.
Make `GIT_CHECKOUT_SAFE` the default. `NONE` is never what the user
wants _by default_; people expect checkout to, well, check things out.
Instead, it should be an opt-in "dry run" mode.
This removes some odd code in internal callers of `checkout` that takes
a `git_checkout_options` and updates the mode to `SAFE`. This is now
unnecessary since everything has better defaults.
This PR ensures and enforces C90 conformance for all files C, including tests.
* Modify CMakeLists.txt to mandate C90 conformance (for better compiler compatibility)
* Update deps/ntlmclient/utf8.h to latest version
* Modify two tests and one header to use C comments instead of C++ comments
