With Git for Windows >= 2 the share folder is in an architecture specific subfolder.

This also add support for Git for Windows versions between 2 and 2.24 where also the etc folder is in an architecture specific subfolder.

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

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

Removal of the last 4 chars is only required for Git for Windows installations in order to find the "root" folder of the Git installation.

Fixes issue #5127.

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

Could happen if the path to git.exe is near to MAX_PATH and we append a longer subdir such as "share/git-core" to it.

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

Support scp style paths with ports

Fix typos

Instead of trying to figure out a repo's path from a URL by hand, parse
a URL using the parsing functionality.

We occasionally need to determine whether a given string is a URL or
something else.  (The "something else" may be a git path in a different
format, like scp formatting, which needs to be handled differently.)

Provide a mechanism for parsing scp-style paths (eg
`git@github.com:libgit2/libgit2` into the url form
`ssh://git@github.com/libgit2/libgit2`.)

GitHub is removing support for the unauthenticated git protocol; test
with the https protocol.

remote: support `http.followRedirects` (`false` and `initial`) and follow initial redirects by default

c99: change single bit flags to unsigned

Test that we honor `http.followRedirects` when set to initial or false.

Give callers the ability to select how to handle redirects - either
supporting redirects during the initial connection (so that, for
example, `git.example.com/repo` can redirect to `github.com/example/repo`)
or all/no redirects.  This is for compatibility with git.

In redirect application logic, (optionally) allow off-site redirects.

We (thankfully) don't have flaky tests anymore, don't retry them.

The new version of our test git server adds redirect support.  Upgrade
to it.

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