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.
For consistency, specify the nanosecond option in the same way as other
options, and identify it as such. Split the detection of platform
support (`FindStatNsec`) and its selection (`SelectNsec`).
The `USE_` prefix for inputs denotes a backend; the `DEBUG_` prefix
denotes a debugging option. Make `DEBUG_LEAK_CHECKER` the name of the
leak checking option.
Selecting regular expression backend should be specified in the same way
as everything else; `USE_REGEX`. Keep `REGEX_BACKEND` as an optional
fallback.
When specifying a separate working directory path, the given repository
path should never have a `.git` directory created beneath it. That
simply doesn't make sense.
As a result, the `GIT_REPOSITORY_INIT_NO_DOTGIT_DIR` now _also_ no
longer makes sense. It would only ever be a sensible option when one
wanted a separate `.git` directory and working directory, otherwise the
git files and working directory files would be comingled. Remove the
option entirely.
Don't build docs on pushes to maint branches; those docs should only be
built _on release_. In addition, be safer about not creating an existing
branch from a tracking branch.
git's hash algorithm is sha1dc, it is not sha1. Per Linus:
> Honestly, git has effectively already moved from SHA1 to SHA1DC.
>
> So the actual known attack and weakness of SHA1 should simply not be
> part of the discussion for the next hash. You can basically say "we're
> _already_ on the second hash, we just picked one that was so
> compatible with SHA1 that nobody even really noticed.
Warn users who try to compile with SHA1 instead of SHA1DC.
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.
