A git_config_entry now knows the type of the origin for the entry
("file", "memory", etc) and the path details (for files, the path on
disk). This is propagated through snapshots.

The opaque `payload` on an entry is unnecessary and distracting; config
entries should follow the patterns of other objects and use space
elsewhere in the structure with a "base" config entry struct embedded.

Don't set entry data when we "get" an entry from the collection, add the
data to the entry before it's put into the collection. This keeps the
entry creation logic in a single place.

repository: make cleanup safe for re-use with grafts

We are allowed to call `git_repository__cleanup` multiple times, and this
happens e.g. in rugged if we want to free up resources before GC gets around to
them.

This means that we cannot leave dangling pointers in it, which we were doing
with the grafts. Fix this by setting the pointers to NULL after freeing the resources.

meta: update version numbers to v1.8

v1.7: release Kleine Raupe Nimmersatt

deps: update pcre to 8.45

#6576 git_diff_index_to_workdir reverse now loads untracked content

tests: add allocator with limited number of bytes

Fixes #6344: git_branch_move now renames the reflog instead of deleting.

Partial fix for #6532: insert-by-date order.

midx: do not try to look at every object in the index

pack: cast the number of objects to size_t

CMake: Search for ssh2 instead of libssh2.

midx: allow unknown chunk ids in multi-pack index files

docs: fix IRC server from freenode to libera

This commit update the contributing documents with the
new IRC server and remove the old freenode.

Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>

Fixes "CMake Error: could not resolve ssh2" on Windows-MSVC.

Similar to previous issues around doing way too much verification at loading
time, checking whether the object index chunk is monotonic is better left for
git-fsck instead of every single time we want to look at something in the
repository.

As midx files grow, this starts taking more and more times. As an example, I
went looking for this because it's taking about 1.5s to do a single object
lookup in a repository that's ended up with a 7G multi-pack-index file.

Similar to a previous change where we had to change the casting when loading the
index file, we also need to make sure we don't restrict the numbers to 32-bit
when looking up objects in packfiles.

This was done about three years ago in git itself, but we never got he update in
this library.

These chunks work like extensions where it's fine not to know what one means. We
can skip over it and keep processing the file instead of erroring out.

When a worktree is not prunable, an error message will be set with
information about why. Document that.

PR #5712 predates several refactorings to move the utility code into a
more general purpose codebase. Update to reflect the refactorings.

Fixes #5598

Avoid passing a `NULL` ptr to `memcpy` -- that's UB (even if size is 0)

Test that `git_buf` correctly fails if no more bytes can be allocated.
This is mostly for demonstration purposes.

In several circumstances, we get bug reports about things that happen in
situations where the environment is quite limited with regards to
available memory. While it's expected that functionality will fail if
memory allocations fail, the assumption is that we should do so in a
controlled way. Most importantly, we do not want to crash hard due to
e.g. accessing NULL pointers.

Naturally, it is quite hard to debug such situations. But since our
addition of pluggable allocators, we are able to implement allocators
that fail in deterministic ways, e.g. after a certain amount of bytes
has been allocated. This commit does exactly that.

To be able to properly keep track of the amount of bytes currently
allocated, allocated pointers contain tracking information. This
tracking information is currently limited to the number of bytes
allocated, so that we can correctly replenish them on calling `free` on
the pointer. In the future, it would be feasible to extend the tracked
information even further, e.g. by adding information about file and line
where the allocation has been performed. As this introduced some
overhead to allocations though, only information essential to limited
allocations is currently tracked.