A reparse point that is an IO_REPARSE_TAG_MOUNT_POINT could be
a junction or an actual filesystem mount point.  (Who knew?)
If it's the latter, its reparse point will report the actual
volume information \??\Volume{GUID}\ and we should not attempt
to dereference that further, instead readlink should report
EINVAL since it's not a symlink / junction and its original
path was canonical.

Yes, really.

Some PRs have fallen out of sync with the changes in signatures, so we
need to take a few extra parameters into account.

Can read large file larger than 2GB on Win64

Fix warnings in thread-utils.h when building without -DTHREADSAFE=ON

Do not error out when fetching from second remote

Provide option to embed libssh2

Add support for setting the SSL CA location

Allow to propagate checkout callbacks to git HARD reset

Provide host name to certificate_check_cb

New test files for the javascript diff driver.

Walk only as far as the common ancestors of uninteresting commits

Treat an empty list of refspecs the same as a NULL value.

Implement git-describe

config: Handle multiple spaces that follow a configuration value and precede a comment char

Fix README.md

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

Trivial fixups

Introduce reference transactions

Implement opportunistic ref updates

This leaves space for future expansion to locking other resources
without having to change the API for references.

Add `git_merge_bases_many`

This should have been included when implementing the feature but was
missed.

If there have been no pushes, we can immediately return ITEROVER. If
there have been no hides, we must not run the uninteresting pre-mark
phase, as we do not want to hide anything and this would simply cause us
to spend time loading objects.

This introduces a phase at the start of preparing a walk which pre-marks
uninteresting commits, but only up to the common ancestors.

We do this in a similar way to git, by walking down the history and
marking (which is what we used to do), but we keep a time-sorted
priority queue of commits and stop marking as soon as there are only
uninteresting commits in this queue.

This is a similar rule to the one used to find the merge-base. As we
keep inserting commits regardless of the uninteresting bit, if there are
only uninteresting commits in the queue, it means we've run out of
interesting commits in our walk, so we can stop.

The old mark_unintesting() logic is still in place, but that stops
walking if it finds an already-uninteresting commit, so it will stop on
the ones we've pre-marked; but keeping it allows us to also hide those
that are hidden via the callback.

The old separation was due to the old merge-base finding, so it's no
longer necessary.

These store merge-base information which is only valid for a single run.