Clear up some of the various "find" functions and the snapshot
API naming to be things I like more.

This makes the lock management on the index a little bit broader,
having a number of routines hold the lock across looking up the
item to be modified and actually making the modification.  Still
not true thread safety, but more pure index modifications are now
safe which allows the simple cases (such as starting up a diff
while index modifications are underway) safe enough to get the
snapshot without hitting allocation problems.

As part of this, I simplified the allocation of index entries to
use a flex array and just put the path at the end of the index
entry.  This makes every entry self-contained and makes it a
little easier to feel sure that pointers to strings aren't
being accidentally copied and freed while other references are
still being held.

This adds a basic test of doing simultaneous diffs on multiple
threads and adds basic locking for the attr file cache because
that was the immediate problem that arose from these tests.

This makes the index iterator honor the GIT_ITERATOR_IGNORE_CASE
and GIT_ITERATOR_DONT_IGNORE_CASE flags without modifying the
index data itself.  To take advantage of this, I had to export a
number of the internal index entry comparison functions.  I also
wrote some new tests to exercise the capability.

This surrounds any function that mutates the entries vector with
a mutex so it can be safely snapshotted.

The usefulness of these helpers came up for me while debugging
some of the iterator changes that I was making, so since they
have also been requested (albeit indirectly) I thought I'd include
them.

Again, laying groundwork for some index iterator changes, this
contains a bunch of code refactorings for index internals that
should make it easier down the line to add locking around index
modifications.  Also this removes the redundant prefix_position
function and fixes some potential memory leaks.

This is just laying some groundwork for internal index changes
that I'm working on.

Support for format-patch

Add GIT_BRANCH_LOCAL_AND_REMOTE to git_branch_t enum

git_branch_t is an enum so requesting GIT_BRANCH_LOCAL | GIT_BRANCH_REMOTE is not possible as it is not a member of the enum (at least VS2013 C++ complains about it).

This fixes a regression introduced in commit a667ca82 (PR #1946).

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

Fix core.excludesfile named .gitignore

Add cherry pick support

It will form part of the subject line and should thus be one line.

Introduce git_diff_get_stats, git_diff_stats_files_changed, git_diff_stats_insertions, git_diff_stats_deletions and git_diff_stats_to_buf

Ignore rules with slashes in them are matched using FNM_PATHNAME
and use the path to the .gitignore file from the root of the
repository along with the path fragment (including slashes) in
the ignore file itself.  Unfortunately, the relative path to the
.gitignore file was being applied to the global core.excludesfile
if that was also named ".gitignore".

This fixes that with more precise matching and includes test for
ignore rules with leading slashes (which were the primary example
of this being broken in the real world).

This also backports an improvement to the file context logic from
the threadsafe-iterators branch where we don't rely on mutating
the key of the attribute file name to generate the context path.

Correct C90 warnings

Fix bug popping ignore files during wd iteration

There were a couple bugs in popping ignore files during iteration
that could result in incorrect decisions be made and thus ignore
files below the root either not being loaded correctly or not
being popped at the right time.

One bug was an off-by-one in comparing the path of the gitignore
file with the path being exited during iteration.

The second bug was not correctly truncating the path being tracked
during traversal if there were no ignores on the list (i.e. when
you have no .gitignore at the root, but do have some in contained
directories).

Allows for inserting the same character n amount of times

Rewrite `state-cleanup`

Update treatment of submodule-like directories with tracked content in the parent

pull userdiff pattern updates from git.git

This is the moral equivalent of

  git/git@39a87a29ce364ed3337e535adce5973731ba2968

from Adrian Johnson <ajohnson@redneon.com>.

This pulls upstream changes from:

  git/git@8a2e8da367f7175465118510b474ad365161d6b1

  git/git@abf8f9860248d8c213600974742f18dadaa8fbb5

  git/git@407e07f2a6f55e605fda9e90cb622887269f68b5

all by Johannes Sixt <j6t@kdbg.org>.

This updates how libgit2 treats submodule-like directories that
actually have tracked content inside of them.  This is a strange
corner case, but it seems that many people have abortive submodule
setups and then just went ahead and added the files into the
parent repository.  In this case, we should just treat the
submodule as if it was a normal directory.

Libgit2 will still try to skip over real submodules and contained
repositories that do not have tracked files inside them, but this
adds some new handling for cases where the apparently submodule
data is in conflict with the actual list of tracked files.