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.
Users can now override the "product" portion of the user-agent (via
GIT_OPT_SET_USER_AGENT_PRODUCT). This continues to default to "git/2.0",
but users may define their own string, or may opt out of sending a
user-agent entirely (by passing an empty string). Similarly, users may
now also opt-out of sending any additional "comment" information by
setting the GIT_OPT_SET_USER_AGENT value to an empty string.
Make socket I/O non-blocking and add optional timeouts.
Users may now set `GIT_OPT_SET_SERVER_CONNECT_TIMEOUT` to set a shorter
connection timeout. (The connect timeout cannot be longer than the
operating system default.) Users may also now configure the socket read
and write timeouts with `GIT_OPT_SET_SERVER_TIMEOUT`.
By default, connects still timeout based on the operating system
defaults (typically 75 seconds) and socket read and writes block.
Add a test against our custom testing git server that ensures that we
can timeout reads against a slow server.
Some callers -- like our test suite and the test suites of our language
bindings -- want to isolate the home directory to avoid accidentally
including the executing user's actual home directory data.
Previously, we combined the notion of a home directory and global
configuration -- now that this is separated, we provide users the
ability to configure both.
Allow users to specify additional repository extensions that they want
to support. For example, callers can specify that they support
`preciousObjects` and then may open repositories that support
`extensions.preciousObjects`.
Similarly, callers may opt out of supporting extensions that the library
itself supports.
Introduce GIT_OPT_SET_ODB_LOOSE_PRIORITY and GIT_OPT_SET_ODB_PACKED_PRIORITY
to allow overriding the default priority values for the default ODB
backends. Libgit2 has historically assumed that most objects for long-
running operations will be packed, therefore GIT_LOOSE_PRIORITY is
set to 1 by default, and GIT_PACKED_PRIORITY to 2.
When a client allows libgit2 to set the default backends, they can
specify an override for the two priority values in order to change
the order in which each ODB backend is accessed.
* Change the default of the file limit to 0 (unlimited).
* Changed the heuristic to close files to be the file that contains the
least-recently-used window such that the window is the
most-recently-used in the file, and the file does not have in-use
windows.
* Parameterized the filelimit test to check for a limit of 1 and 100
open windows.
There are some cases in which repositories accrue a large number of
packfiles. The existing mwindow limit applies only to the total size of
mmap'd files, not on their number. This leads to a situation in which
having lots of small packfiles could exhaust the allowed number of open
files, particularly on macOS, where the default ulimit is very low
(256).
This change adds a new configuration parameter
(GIT_OPT_SET_MWINDOW_FILE_LIMIT) that sets the maximum number of open
packfiles, with a default of 128. This is low enough so that even macOS
users should not hit it during normal use.
Based on PR #5386, originally written by @josharian.
Fixes: #2758
Allow users to opt-in to expect/continue handling when sending a POST
and we're authenticated with a "connection-based" authentication
mechanism like NTLM or Negotiate.
If the response is a 100, return to the caller (to allow them to post
their body). If the response is *not* a 100, buffer the response for
the caller.
HTTP expect/continue is generally safe, but some legacy servers
have not implemented it correctly. Require it to be opt-in.
Remove an `inttypes.h` header that is too large in scope, and far too
public.
For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need
to include `stdint.h` in our public headers, for types like `uint32_t`.
Internally, we also need to define `PRId64` as a printf formatting
string when it is not available.
Since we now always build the library with cdecl calling conventions,
our callbacks should be decorated as such so that users will not be able
to provide callbacks defined with other calling conventions.
The `GIT_CALLBACK` macro will inject the `__cdecl` attribute as
appropriate.
The recommendation from engineers within Microsoft is that libraries
should have a calling convention specified in the public API, and that
calling convention should be cdecl unless there are strong reasons to
use a different calling convention.
We previously offered end-users the choice between cdecl and stdcall
calling conventions. We did this for presumed wider compatibility: most
Windows applications will use cdecl, but C# and PInvoke default to
stdcall for WINAPI compatibility. (On Windows, the standard library
functions are are stdcall so PInvoke also defaults to stdcall.)
However, C# and PInvoke can easily call cdecl APIs by specifying an
annotation.
Thus, we will explicitly declare ourselves cdecl and remove the option
to build as stdcall.
git_object_t is the future; update the public API to use it. This will
also ensure that we can build our tests which make use of the old API
without modification (and without compiler warnings).
Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause
commands that reload the on-disk index to fail if the current
`git_index` has changed that have not been saved. This will prevent
users from - for example - adding a file to the index then calling a
function like `git_checkout` and having that file be silently removed
from the index since it was re-read from disk.
Now calls that would re-read the index will fail if the index is
"dirty", meaning changes have been made to it but have not been written.
Users can either `git_index_read` to discard those changes explicitly,
or `git_index_write` to write them.
Tie in the newly created infrastructure for swapping out memory
allocators into our settings code. A user can now simply use the new
option "GIT_OPT_SET_ALLOCATOR" with `git_libgit2_opts`, passing in an
already initialized allocator structure as vararg.
Initially, the setting has been solely used to enable the use of
`fsync()` when creating objects. Since then, the use has been extended
to also cover references and index files. As the option is not yet part
of any release, we can still correct this by renaming the option to
something more sensible, indicating not only correlation to objects.
This commit renames the option to `GIT_OPT_ENABLE_FSYNC_GITDIR`. We also
move the variable from the object to repository source code.
Verifying hashsums of objects we are reading from the ODB may be costly
as we have to perform an additional hashsum calculation on the object.
Especially when reading large objects, the penalty can be as high as
35%, as can be seen when executing the equivalent of `git cat-file` with
and without verification enabled. To mitigate for this, we add a global
option for libgit2 which enables the developer to turn off the
verification, e.g. when he can be reasonably sure that the objects on
disk won't be corrupted.
This can prevent FILE_SHARED_VIOLATIONS when used in tools such as TortoiseGit TGitCache and FILE_SHARE_DELETE, because files can be opened w/o being locked any more.
Signed-off-by: Sven Strickroth <email@cs-ware.de>
