The existing mechanism for providing options to remote fetch/push calls,
and subsequently to transports, is unsatisfactory.  It requires an
options structure to avoid breaking the API and callback signatures.

1. Introduce `git_remote_connect_options` to satisfy those needs.

2. Add a new remote connection API, `git_remote_connect_ext` that will
   take this new options structure.  Existing `git_remote_connect` calls
   will proxy to that.  `git_remote_fetch` and `git_remote_push` will
   proxy their fetch/push options to that as well.

3. Define the interaction between `git_remote_connect` and fetch/push.
   Connect _may_ be called before fetch/push, but _need not_ be.  The
   semantics of which options would be used for these operations was
   not specified if you specify options for both connect _and_ fetch.
   Now these are defined that the fetch or push options will be used
   _if_ they were specified.  Otherwise, the connect options will be
   used if they were specified.  Otherwise, the library's defaults will
   be used.

4. Update the transports to understand `git_remote_connect_options`.
   This is a breaking change to the systems API.

Several places in the remote code identify an error and then swallow it;
return the error.

Push starts by connecting, don't try to connect again, just rely on the
existing connection existing.

config: handle empty conditional in includeIf

Add `rename_threshold` to `git_status_options`.

When a config file contains `[includeIf]` (with no condition), we should
treat that as a falsey value.  This means that we should properly parse
a config value of `includeIf.path`.

ntmlclient: fix linking with libressl

Remove PSGit from Language Bindings section of README

PSGit is not using libgit2 library. It is stub of a library and is not developed further.

ci: build with ssh on nightly

remote: refactor insteadof application

Using the insteadof helper would leak memory when we didn't really want
the pushInsteadOf configuration.  Refactor the choice into the function
that allocates memory (or now, not) and use a more idiomatic `int`
return code.

See commit f0e693b1

Since we are able to give our own git checkout options,
the default git checkout strategy will be the same as
initialized in a new git_checkout_options struct.

Extend the `git_worktree_add_options` to include `git_checkout_options`.

github issue #5949

blob: identify binary content

Config parsing

git_commit_summary: ignore lines with spaces

remotes: fix insteadOf/pushInsteadOf handling

Better revparse compatibility for at time notation

Fix a long long that crept past

cmake: use project-specific root variable instead of CMAKE_SOURCE_DIR

Also applies to *_BINARY_DIR.

This effectively reverts 84083dcc,
which broke all users of libgit2 that use it as a CMake subdirectory
(via `add_subdirectory()`). This is because CMAKE_SOURCE_DIR refers
to the root-most CMake directory, which in the case of
`add_subdirectory()` is a parent project to libgit2 and thus the paths
don't make any sense to the configuration files. Corollary,
CMAKE_SOURCE_DIR only makes sense if the CMake project is always the
root project - which can rarely be guaranteed.

In all honesty, CMake should deprecate and eventually remove
CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. It's been the source of headaches
and confusion for years, they're rarely useful over
CMAKE_CURRENT_(SOURCE|BINARY)_DIR or PROJECT_(SOURCE|BINARY)_DIR,
and they cause a lot of confusing configuration and source
code layouts to boot.

Any time they are used, they break `add_subdirectory()` almost 100% of
the time, cause confusing error messages, and hide subtle bugs.

Introduce `git_blob_data_is_binary` to examine a blob's data, instead of
the blob itself.  A replacement for `git_buf_is_binary`.

(fixes issue #6088)

Signed-off-by: Sven Strickroth <email@cs-ware.de>