Enable CMake policy CMP0042, if supported:

> CMake 2.8.12 and newer has support for using ``@rpath`` in a target's
> install name.  This was enabled by setting the target property
> ``MACOSX_RPATH``.  The ``@rpath`` in an install name is a more
> flexible and powerful mechanism than ``@executable_path`` or
> ``@loader_path`` for locating shared libraries.

We can use policy checks to see if a policy exists in cmake, like
CMP0051, instead of relying on the version.

sysdir: do not use environment in setuid case

Consistent header guards

attr: avoid stat'ting files for bare repositories

In order to derive the location of some Git directories, we currently
use the environment variables $HOME and $XDG_CONFIG_HOME. This might
prove to be problematic whenever the binary is run with setuid, that is
when the effective user does not equal the real user. In case the
environment variables do not get sanitized by the caller, we thus might
end up using the real user's configuration when doing stuff as the
effective user.

The fix is to use the passwd entry's directory instead of $HOME in this
situation. As this might break scenarios where the user explicitly sets
$HOME to another path, this fix is only applied in case the effective
user does not equal the real user.

use consistent names for the #include / #define header guard pattern.

Depending on whether the path we want to look up an attribute for is a
file or a directory, the fnmatch function will be called with different
flags. Because of this, we have to first stat(3) the path to determine
whether it is a file or directory in `git_attr_path__init`. This is
wasteful though in bare repositories, where we can already be assured
that the path will never exist at all due to there being no worktree. In
this case, we will execute an unnecessary syscall, which might be
noticeable on networked file systems.

What happens right now is that we always pass the `GIT_DIR_FLAG_UNKOWN`
flag to `git_attr_path__init`, which causes it to `stat` the file itself
to determine its type. As it is calling `git_path_isdir` on the path,
which will always return `false` in case the path does not exist, we end
up with the path always being treated as a file in case of a bare
repository. As such, we can just check the bare-repository case in all
callers and then pass in `GIT_DIR_FLAG_FALSE` ourselves, avoiding the
need to `stat`. While this may not always be correct, it at least is no
different from our current behavior.

Merge example

Honor 'GIT_USE_NSEC' option in `filesystem_iterator_set_current`

Use longer conflict markers in recursive merge base

status::renames: test update for APFS (write NFD instead of NFC filename)

This should have been part of PR #3638. Without this we still get 
nsec-related errors, even when using -DGIT_USE_NSEC:

 error: ‘struct stat’ has no member named ‘st_mtime_nsec’

Special-casing null OIDs

README.md: add notes on how to report security issues

The null OID (hash with all zeroes) indicates a missing object in
upstream git and is thus not a valid object ID. Add defensive
measurements to avoid writing such a hash to the object database in the
very unlikely case where some data results in the null OID. Furthermore,
add shortcuts when reading the null OID from the ODB to avoid ever
returning an object when a faulty repository may contain the null OID.

In commit a96d3cc3f (cache-tree: reject entries with null sha1,
2017-04-21), the git.git project has changed its stance on null OIDs in
tree objects. Previously, null OIDs were accepted in tree entries to
help tools repair broken history. This resulted in some problems though
in that many code paths mistakenly passed null OIDs to be added to a
tree, which was not properly detected.

Align our own code base according to the upstream change and reject
writing tree entries early when the OID is all-zero.

odb: export mempack backend

Fixes #4492, #4496.

Update the status::renames test to create an NFD format filename in the
core.precomposedunicode tests.

Previously, we would create an NFC format filename.  This was to take
advantage of HFS+ filesystems, which always use canonically decomposed
formats, and would actually write the filename to disk as an NFD
filename.  So previously, we could create an NFC filename, but read it
normally as an NFD filename.

But APFS formats do not force canonically decomposed formats for
filenames, so creating an NFC filename does not get converted to NFD.
Instead, the filename will be written in NFC format.  Our test,
therefore, does not work - when we write an NFC filename, it will
_remain_ NFC.

Update the test to write NFD always.  This will ensure that the file
will actually be canonically decomposed on all platforms:  HFS+, which
forces NFD, and APFS, which does not.

Thus, our test will continue to ensure that an NFD filename is
canonically precomposed on all filesystems.

Git uses longer conflict markers in the recursive merge base - two more
than the default (thus, 9 character long conflict markers).  This allows
users to tell the difference between the recursive merge conflicts and
conflicts between the ours and theirs branches.

This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.

Update our tests to expect this as well.

Allow for a custom conflict marker size, allowing callers to override
the default size of the "<<<<<<<" and ">>>>>>>" markers in the
conflicted output file.

branch: refuse creating branches named 'HEAD'

refs: include " sorted " in our packed-refs header

message: update docs for git_message_prettify

tests: online::clone: fix memory leak due to not freeing URL

Since a625b092c (branch: correctly reject refs/heads/{-dash,HEAD},
2017-11-14), which is included in v2.16.0, upstream git refuses to
create branches which are named HEAD to avoid ambiguity with the
symbolic HEAD reference. Adjust our own code to match that behaviour and
reject creating branches names HEAD.