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.
The initialization of the on-disk state of refdbs is currently not
handled by the actual refdb backend, but it's implemented ad-hoc where
needed. This is problematic once we have multiple different refdbs as
the filesystem structure is of course not the same.
Introduce a new callback function `git_refdb_backend::init()`. If set,
this callback can be invoked via `git_refdb_init()` to initialize the
on-disk state of a refdb. Like this, each backend can decide for itself
how exactly to do this.
Note that the initialization of the refdb is a bit intricate. A
repository is only recognized as such when it has a "HEAD" file as well
as a "refs/" directory. Consequently, regardless of which refdb format
we use, those files must always be present. This also proves to be
problematic for us, as we cannot access the repository and thus don't
have access to the refdb if those files didn't exist.
To work around the issue we thus handle the creation of those files
outside of the refdb-specific logic. We actually use the same strategy
as Git does, and write the invalid reference "ref: refs/heads/.invalid"
into "HEAD". This looks almost like a ref, but the name of that ref
is not valid and should thus trip up Git clients that try to read that
ref in a repository that really uses a different format.
So while that invalid "HEAD" reference will of course get rewritten by
the "files" backend, other backends should just retain it as-is.
While we only support initializing repositories with the "files"
reference backend right now, we are in the process of implementing a
second backend with the "reftable" format. And while we already have the
infrastructure to decide which format a repository should use when we
open it, we do not have infrastructure yet to create new repositories
with a different reference format.
Introduce a new field `git_repository_init_options::refdb_type`. If
unset, we'll default to the "files" backend. Otherwise though, if set to
a valid `git_refdb_t`, we will use that new format to initialize the
repostiory.
Note that for now the only thing we do is to write the "refStorage"
extension accordingly. What we explicitly don't yet do is to also handle
the backend-specific logic to initialize the refdb on disk. This will be
implemented in subsequent commits.
To support multiple different reference backend implementations,
Git introduced a "refStorage" extension that stores the reference
storage format a Git client should try to use.
Wire up the logic to read this new extension when we open a repository
from disk. For now, only the "files" backend is supported by us. When
trying to open a repository that has a refstorage format that we don't
understand we now error out.
There are two functions that create a new repository that doesn't really
have references. While those are mostly non-functional when it comes to
references, we do expect that you can access the refdb, even if it's not
yielding any refs. For now we mark those to use the "files" backend, so
that the status quo is retained. Eventually though it might not be the
worst idea to introduce an explicit "in-memory" reference database. But
that is outside the scope of this patch series.
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.
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.
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
