putting `0.` at the start of the line turns it into a numbered list.

Treat GIT_PASSTHROUGH as though git_cred_acquire_cb isn't set.

Line count overflow in git_blame_hunk and git_blame__entry

diff: include commit message when formatting patch

index: always queue `remove_entry` for removal

reset: perform the checkout before moving HEAD or the index

This keeps the state of the workdir the same as one from HEAD, removing
a source of possible confusion when calculating the work that is to be
done.

Use a typedef for the submodule_foreach callback.

tree: mark a tree as already sorted

This fits with the style for the rest of the project, but more
importantly, makes life easier for bindings authors who auto-generate
code.

When replacing an index with a new one, we need to iterate
through all index entries in order to determine which entries are
equal. When it is not possible to re-use old entries for the new
index, we move it into a list of entries that are to be removed
and thus free'd.

When we encounter a non-zero error code, though, we skip adding
the current index entry to the remove-queue. `INSERT_MAP_EX`,
which is the function last run before adding to the remove-queue,
may return a positive non-zero code that indicates what exactly
happened while inserting the element. In this case we skip adding
the entry to the remove-queue but still continue the current
operation, leading to a leak of the current entry.

Fix this by checking for a negative return value instead of a
non-zero one when we want to add the current index entry to the
remove-queue.

The trees are sorted on-disk, so we don't have to go over them
again. This cuts almost a fifth of time spent parsing trees.

CMakeLists: Compare CMAKE_SIZEOF_VOID_P as a number, not as a string

checkout test: Apply umask to file-mode test as well

tree: use a specialised mode parse function

index: canonicalize inserted paths safely

When adding to the index, we look to see if a portion of the given
path matches a portion of a path in the index.  If so, we will use
the existing path information.  For example, when adding `foo/bar.c`,
if there is an index entry to `FOO/other` and the filesystem is case
insensitive, then we will put `bar.c` into the existing tree instead
of creating a new one with a different case.

Use `strncmp` to do that instead of `memcmp`.  When we `bsearch`
into the index, we locate the position where the new entry would
go.  The index entry at that position does not necessarily have
a relation to the entry we're adding, so we cannot make assumptions
and use `memcmp`.  Instead, compare them as strings.

When canonicalizing paths, we look for the first index entry that
matches a given substring.

Instead of going out to strtol, which is made to parse generic numbers,
copy a parse function from git which is specialised for file modes.

Fix the file-mode test to expect system umask being applied to the
created file as well (it is currently applied to the directory only).
This fixes the test on systems where umask != 022.

Signed-off-by: Michał Górny <mgorny@gentoo.org>

tree: mark cloned tree entries as un-pooled

When duplicating a `struct git_tree_entry` with
`git_tree_entry_dup` the resulting structure is not allocated
inside a memory pool. As we do a 1:1 copy of the original struct,
though, we also copy the `pooled` field, which is set to `true`
for pooled entries. This results in a huge memory leak as we
never free tree entries that were duplicated from a pooled
tree entry.

Fix this by marking the newly duplicated entry as un-pooled.

When formatting a patch as email we do not include the commit's
message in the formatted patch output. Implement this and add a
test that verifies behavior.

It is already possible to get a commit's summary with the
`git_commit_summary` function. It is not possible to get the
remaining part of the commit message, that is the commit
message's body.

Fix this by introducing a new function `git_commit_body`.

The `git_blame__entry` struct keeps track of line counts with
`int` fields. Since `int` is only guaranteed to be at least 16
bits we may overflow on certain platforms when line counts exceed
2^15.

Fix this by instead storing line counts in `size_t`.

It is not unreasonable to have versioned files with a line count
exceeding 2^16. Upon blaming such files we fail to correctly keep
track of the lines as `git_blame_hunk` stores them in `uint16_t`
fields.

Fix this by converting the line fields of `git_blame_hunk` to
`size_t`. Add test to verify behavior.

Improvements to tree parsing speed

Compiler warning fixes

Return an error in case the length is too big. Also take this
opportunity to have a single allocating function for the size and
overflow logic.

Recursive Merge

This reduces the size of the struct from 32 to 26 bytes, and leaves a
single padding byte at the end of the struct (which comes from the
zero-length array).

We already know the size due to the `memchr()` so use that information
instead of calling `strlen()` on it.

These are rather small allocations, so we end up spending a non-trivial
amount of time asking the OS for memory. Since these entries are tied to
the lifetime of their tree, we can give the tree a pool so we speed up
the allocations.

We've already looked at the filename with `memchr()` and then used
`strlen()` to allocate the entry. We already know how much we have to
advance to get to the object id, so add the filename length instead of
looking at each byte again.