git_remote_set_transport now takes a transport factory rather than a transport
git_clone_options now allows the caller to specify a remote creation callback

Fix a couple of leaks

Set a message when we fail to lock.

Also make the put function void, since it's called from free, which
cannot report errors. The only errors we can experience here are
internal state corruption, so we assert that we are trying to put a
pack which we have previously got.

As reported by coverity, we would leak some memory in error conditions.

If we fail to insert the packfile in the map, make sure to free it.

This makes the free function only attempt to remove its mwindows from
the global list if we have opened the packfile to avoid accessing the
list unlocked.

We need to tell Travis to build the master branch or it won't build it
or the pull requests.

Update text=auto / core.autocrlf=false behavior

Export git_revert_commit

Git for Windows 1.9.4 changed the behavior when the text=auto
attribute is specified and core.autocrlf=false.  Previous observed
behavior would *not* filter files when going into the working
directory, the new behavior *does* filter.  Update our behavior to match.

Update CONTRIBUTING and PROJECTS

When checking out files, we're performing conversion into the user's
native line endings, but we only want to do it for files which have
consistent line endings. Refuse to perform the conversion for mixed-EOL
files.

The CRLF->LF filter is left as-is, as that conversion is considered to be
normalization by git and should force a conversion of the line endings.

Opening the same repository multiple times will currently open the same
file multiple times, as well as map the same region of the file multiple
times. This is not necessary, as the packfile data is immutable.

Instead of opening and closing packfiles directly, introduce an
indirection and allocate packfiles globally. This does mean locking on
each packfile open, but we already use this lock for the global mwindow
list so it doesn't introduce a new contention point.

This updates CONTRIBUTING to reflect the changes to use the
master branch and make explicit recommendations about updating
CHANGELOG.md and providing test coverage.  Also, this includes
some old updates to PROJECTS.md that I wrote to expand the list
of projects, pulling in things from old feature requests.

Don't use read-write accounts for the tests

netops: init OpenSSL once under lock

The assembla failure we were seeing referred to a private repository,
which is not what is there at the moment.

This reverts 1fd21b03

Don't write in plaintext the password of an account which has full
control over the repository. Instead use an account with read-only
access.

We want to check whether the credentials callback is NULL, not whether
the payload is.

Bring together all of the OpenSSL initialization to
git_threads_init() so it's together and doesn't need locks.

Moving it here also gives us libssh2 thread safety (when built against
openssl).

OpenSSL's tests init everything in the main thread, so let's do that.

When using in a multithreaded context, OpenSSL needs to lock, and leaves
it up to application to provide said locks.

We were not doing this, and it's just luck that's kept us from crashing
up to now.

Add docs for git_clone_local_t and move the docs for the
git_clone_options to each field.

The OpenSSL init functions are not reentrant, which means that running
multiple fetches in parallel can cause us to crash.

Use a mutex to init OpenSSL, and since we're adding this extra checks,
init it only once.

revwalk: more sensible array handling

Instead of using a sentinel empty value to detect the last commit, let's
check for when we get a NULL from popping the stack, which lets us know
when we're done.

The current code causes us to read uninitialized data, although only on
RHEL/CentOS 6 in release mode. This is a readability win overall.

We can simply ask the hasmap.

If the user wants to keep a copy for themselves, they should make a
copy. It adds unnecessary complexity to make sure the returned entries
are valid until the builder is cleared.

Finding a filename in a vector means we need to resort it every time we
want to read from it, which includes every time we want to write to it
as well, as we want to find duplicate keys.

A hash-map fits what we want to do much more accurately, as we do not
care about sorting, but just the particular filename.

We still keep removed entries around, as the interface let you assume
they were going to be around until the treebuilder is cleared or freed,
but in this case that involves an append to a vector in the filter case,
which can now fail.

The only time we care about sorting is when we write out the tree, so
let's make that the only time we do any sorting.