At present, the library's oid manipulation functions are slower when
built in SHA256 mode than when not. Add some microbenchmarks around the
oid compare and copy functions to understand this better.
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.
Since git_oid_raw_cmp uses memcmp, it's far easier to optimise more aggressively.
Given that it's static const and used inlined, it seems reasonable to assume that git_oid_zero will be optimised away in release.
This is at least the case with x86-64 and GCC 15.2.1.
Preserve ref-advertised capabilities when only the stream is reset.
This prevents losing `object-format` before `git_remote_oid_type()`
and fixes SHA256 clone pack trailer mismatch.
Fixeslibgit2/libgit2#7182
These are SHA256 TODO leftover.
In the surrounding context they all have the required oid type around,
so I just picked up them and pass in.
Found during SHA256 support integration with Rust git-rs binding
The expression (c & 0x7f) << shift in hdr_sz() causes undefined
behavior when shift >= 32, because (c & 0x7f) is an unsigned int
(32-bit type). A malicious delta with a long varint can trigger this.
Fix by:
1. Casting to size_t before shifting to support 64-bit shifts
2. Adding a shift limit check to reject overlong varints
