Use statistics (like core git) to control the behavior of the
to workdir CRLF filter.

Support hierarchical test resource data, such that you can have
`tests/resources/foo/bar` and move the `bar` directory in as
a fixture.

Calling `cl_fixture_sandbox` on a path that is not directly beneath
the test resources directory succeeds, placing that directory into
the test fixture.  (For example, `cl_fixture_sandbox("foo/bar")`
will sandbox the `foo/bar` directory as `bar`).

Add support for cleaning up directories created this way, by only
cleaning up the basename (in this example, `bar`) from the fixture
directory.

A corpus of files checked out with Git (Linux, 1.9.1) to ensure that
produce identical data when checking out using a CRLF filter.

A corpus of files checked out with Git for Windows (2.4.1.windows.1)
to ensure that we produce identical data when checking out using a
CRLF filter.

Given a variety of combinations of core.autocrlf settings and
attributes settings, test that we check out data into the working
directory the same as a known-good test resource created by git.git.

Include a shell script that will generate the expected CRLF data,
calling git.git to capture its output as a test resource for the
current platform.

Include the UTF8 and UTF8 BOM tests in the master crlf test
branch for completeness.

Include additional test data for CRLF tests: files with mixed
line endings and binary files.

commit: allow retrieving an arbitrary header field

Write modified index in git_stash_apply()

This allows the user to look up fields which we don't parse in libgit2,
and allows them to access gpgsig or mergetag fields if they wish to
check the signature.

Same as with git_stash_save(), there's no reason not to write the index
to disk since it has been modified.

Don't propagate workdir's mode to the index during diff's update index

When updating the index during a diff, preserve the original mode,
which prevents us from dropping the mode to what we have interpreted
as on our system (eg, what the working directory claims it to be,
which may be a lie on some systems.)

Test to ensure that when status updates an index, it does not alter
the original mode for file types that are not supported (eg, symlinks
on Windows).

Fixed index being double-freed in stash tests

Use the checksum to check whether an index has been modified

This is used by the submodule in order to figure out if the index has
changed since it last read it. Using a timestamp is racy, so let's make
it use the checksum, just like we now do for reloading the index itself.

Quote LIBSSH2_LIBRARIES call

When ticking over one second, it can happen that the actual time ticks
over the same second between the time that we undermine our own race
protections and the time in which we perform the index update. Such
timing would make the time in the entries match the index' timestamp and
we have not gained anything.

Ticking over five seconds makes it so that if real-time rolls over that
second, our index is still ahead. This is still suboptimal as we're
dealing with timing, but five seconds should be long enough for any
reasonable test runner to finish the tests.

We currently use a timetamp to check whether an index file has been
modified since we last read it, but this is racy. If two updates happen
in the same second and we read after the first one, we won't detect the
second one.

Instead read the SHA-1 checksum of the file, which are its last 20 bytes which
gives us a sure-fire way to detect whether the file has changed since we
last read it.

As we're now keeping track of it, expose an accessor to this data.

This will tell us which numbers we were trying to compare, rather than
just telling us that they're different.

Credits to @directhex

It is possible for PKG_CHECK_MODULES(LIBSSH2 libssh2) to LIBSSH2_LIBRARIES to a string with more than one library in it - e.g. if your libssh2 was built against libgcrypt, it will be "ssh2;gcrypt"

Quoting the string is needed, or CHECK_LIBRARY_EXISTS will fail.

Fixed Xcode 6.1 build warnings

Fix memory leak in tests/network/refspecs.c

Zero out racily-clean entries' file_size

When checking out some file 'foo' that has been modified in the
working directory, allow the checkout to proceed (do not conflict)
if 'foo' is identical to the target of the checkout.

Provide functionality to set the time on a filesystem entry,
using utimes or futimes on POSIX type systems or SetFileTime
on Win32.

commit: ignore multiple author fields

remote: return EINVALIDSPEC when given an empty URL

This is what we used to return in the settter and there's tests in
bindings which ask for this. There's no particular reason to stop doing
so.

Fixed Xcode 6.1 build warnings

These tests want to test that we don't recalculate entries which match
the index already. This is however something we force when truncating
racily-clean entries.

Tick the index forward as we know that we don't perform the
modifications which the racily-clean code is trying to avoid.

In order to avoid racy-git, we zero out the file size for entries with
the same timestamp as the index (or during the initial checkout). This
is the case in a couple of crlf tests, as the code is fast enough to do
everything in the same second.

As we know that we do not perform the modification just after writing
out the index, which is what this is designed to work around, tick the
mtime of the index file such that it doesn't agree with the files
anymore, and we do not zero out these entries.

If a file entry has the same timestamp as the index itself, it is
considered racily-clean, as it may have been modified after the index
was written, but during the same second. We take extra steps to check
the contents, but this is just one part of avoiding races.

For files which do have changes but have not been updated in the index,
updating the on-disk index means updating its timestamp, which means we
would no longer recognise these entries as racy and we would trust the
timestamp to tell us whether they have changed.

In order to work around this, git zeroes out the file-size field in
entries with the same timestamp as the index in order to force the next
diff to check the contents. Do so in libgit2 as well.

We update the index and then immediately change the contents of the
file. This makes the diff think there are no changes, as the timestamp
of the file agrees with the cached data. This is however a bug, as the
file has obviously changed contents.

The test is a bit fragile, as it assumes that the index writing and the
following modification of the file happen in the same second, but it's
enough to show the issue.