This adds a `git_pool` object that can do simple paged memory
allocation with free for the entire pool at once.  Using this,
you can replace many small allocations with large blocks that
can then cheaply be doled out in small pieces.  This is best
used when you plan to free the small blocks all at once - for
example, if they represent the parsed state from a file or data
stream that are either all kept or all discarded.

There are two real patterns of usage for `git_pools`: either
for "string" allocation, where the item size is a single byte
and you end up just packing the allocations in together, or for
"fixed size" allocation where you are allocating a large object
(e.g. a `git_oid`) and you generally just allocation single
objects that can be tightly packed.  Of course, you can use it
for other things, but those two cases are the easiest.

This limitation was a misparsing of the documentation.

Code clean up, including fixing warnings on Windows 64-bit build

Fix git_repository_set_odb() refcount issue

git_repository_free() calls git_odb_free() if the owned odb is not null.

According to the doc, when setting a new odb through git_repository_set_odb() the caller has to take care of releasing the odb by himself.

Signed-off-by: schu <schu-github@schulog.org>

The code used to assume that there had to be data after the newline in
a tree cache extension entry. This isn't true for a childless
invalidated entry if it's the last one, as there won't be any children
nor a hash to take up space.

Adapt the off-by-one comparison to also work in this case. Fixes #633.

Index refcount issue

This fixes all the warnings on win64 except those in deps, which
come from the regex code.

Adds a new public reference function `git_reference_lookup_oid`
that directly resolved a reference name to an OID without returning
the intermediate `git_reference` object (hence, no free needed).

Internally, this adds a `git_reference_lookup_resolved` function
that combines looking up and resolving a reference.  This allows
us to be more efficient with memory reallocation.

The existing `git_reference_lookup` and `git_reference_resolve`
are reimplmented on top of the new utility and a few places in the
code are changed to use one of the two new functions.

This updates to the latest clar which includes the helpers
`cl_assert_equal_s` and `cl_assert_equal_i`.  Convert the code
over to use those and remove the old libgit2-only helpers.

This removes the code for the old status implementation.

Support config value quoting

Variable values may be quoted to include newlines, literal quotes and
other characters. Add support for these and test it.

ifdef GIT_WIN32 helper unposix_path() to avoid unused-function warning
on non-Windows systems.

Signed-off-by: schu <schu-github@schulog.org>

git_repository_free() calls git_index_free() if the owned index is not null.

According to the doc, when setting a new index through git_repository_set_index() the caller has still to take care of releasing the index by itself.

In order to cope with this, this fix makes sure the index refcount is incremented when a new repository is being plugged a new index.

Removed unreferenced variables.

Diff with pathspec

This adds preliminary support for pathspecs to diff and status.
The implementation is not very optimized (it still looks at
every single file and evaluated the the pathspec match against
them), but it works.

Resolve any lingering deltas, write out the index file and rename the
packfile.

This will allow us to index a packfile as soon as we receive it from
the network as well as storing it with its final name so we don't need
to pass temporary file names around.

Update git_repository_open

The new indexer needs to be able to bypass any kind of buffering, as
it's trying to map data that it has just written to disk.

The cleanup needs to happen anyway, so set the error code and jump
there instead of copying the code.

Plug a few leaks

As parents are older than their children, we're appending to the
commit list most of the time, which makes an ordered linked list quite
inefficient.

While we're there, don't sort the results list in the main loop, as
we're sorting them afterwards and it creates extra work.

Nothing should be hidden and this shouldn't bother the merge base
calculation.

There is no need walk down the parents of a merge base to mark them as
uninteresting because we'll never see them. Calculate the merge bases
in prepare_walk() so mark_uninteresting() can stop at a merge base
instead of walking all the way to the root.