Some benchmarks require administrative privileges, namely the ones that
blow up the disk cache. Don't run them by default, to avoid obnoxious
sudo password prompts, etc. Users can specify `--admin` to run them.
The default in the world is to have a disk cache; it's exceptional to
_not_. Flip our naming, so that the (exceptional) `nocache` tests are
called out explicitly.
Introduce `--profile` support to the benchmark helper script, which will
invoke `perf` on Linux. Additionally, add a `--flamegraph` output
option based on that.
It can be useful to report the commit ID during benchmarks to track down
regressions; leverage the addition of that in `git version` during
benchmark runs.
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`.
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.
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`).
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.
In RPC mode (https), the client sends its list of shallow commits at the
beginning of each request during packfile negotiation, so that the
remote endpoint keeps context. This causes the remote to prepend
appropriate shallow/unshallow packets to each response sent back to the
client.
However, the store_common() helper function (used in multi_ack mode)
does not cater for this, returning as soon as it encounters any packet
different than an ACK packet and therefore leaving the rest of the HTTP
buffer unprocessed. This in turn causes subsequent iterations of the
while loop processing ACK packets to process data returned by older HTTP
requests instead of the current one, messing up the packfile negotiation
process. Given that the wait_while_ack() helper function (called after
the client signals to the remote that it is ready to receive packfile
data) correctly skips over shallow/unshallow packets, packfile contents
can still be received successfully in some cases (depending on message
framing); in some other ones, though (particularly when
git_smart__download_pack() processes an HTTP buffer starting with
shallow/unshallow packets), the fetching process fails with an
"incomplete pack header" error due to the flush packet terminating a set
of shallow/unshallow packets being incorrectly interpreted as the flush
packet indicating the end of the packfile (making the code behave as if
no packfile data was sent by the remote).
Fix by ignoring shallow/unshallow packets in the store_common() helper
function, therefore making the ACK processing logic work on the correct
HTTP buffers and ensuring that git_smart__download_pack() is not called
until packfile negotiation is actually finished.
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.
