Avoid retaining / releasing the index more than necessary when GIT_DIFF_...

It turns out that erroring out on duplicate commits is the right thing
to do, but git was not hitting the bug on the server-side.

Bring back a descriptive error message in case of duplicate entries and
error out.

If a packfile includes duplicate objects, we can choose to use the
secon copy instead of the first by using the same logic as if it were
the first.

Change the error condition from 0 to -1, which indicates a bad resize,
and set the OOM message in that case.

This does mean we will leak the first copy of the object. We can deal
with that later, but making fetches work is more important.

While this is not even close to a fix, we can at least set an error
message so we know which error we are facing. Up to know we just
returned an error without a message.

This was but down to 5 when GitHub made a change to their server which
made them stop honouring the include-tag request.

This has recently been corrected, so we can bring it back up to six.

local: create pack with multiple threads

The default behaviour for the packbuilder is to perform the work in a
single thread, which is fine for the public API, but we currently have
no way for a user to determine the number of threads to use when
creating the packfile, which makes our clone behaviour over the
filesystem quite a bit slower than what git offers.

This is a very particular scenario, in which we avoid spawning git by
being ourselves the server-side, so it's probably ok to auto-set the
threading, as the upload-pack process would do if we were talking to
git.

refspec: report errors when parsing an invalid refspec

"In-memory" repos are bare by default

Revert "fastfail" from the mingw PR

If a refspec could not be parsed, the git_refspec__parse function would
return an error value but would not provide additional error information
for the callers. This commit amends that function to set a more useful
error message.

This reverts commit 8008ab6a.

This reverts commit ba6c53b9.

Fixes

RFC: add mingw to appveyor matrix

refdb: use the same id for old and new when renaming a reference

When we rename a reference, we want the old and new ids to be the same
one (as we did not change it). The normal code path looks up the old id
from the current value of the brtanch, but by the time we look it up, it
does not exist anymore and thus we write a zero id.

Pass the old id explicitly instead.

Filter relative paths

branch: fix generated reflog message upon creation

Test that filter_list_apply_to_file works and can accept repo-relative
paths.

these shouldn't be necessary if _WIN32_WINNT >= _WIN32_WINNT_VISTA

should cut down on compiler warnings with mingw

cache mingw-w64 downloads

quiet curl and 7zip

run appveyor steps in cmd for mingw