(The list is ordered by surname, right?)

It's the same as the post-checkout hook, doing the same job. I thought
about symlinking instead of copying, but something doesn't sit quite
right about that.

If the user is running `git commit` to resolve a conflict, it's
dangerous to just save the metadata from the filesystem. It's possible
that they just fixed a conflict in the metadata file, but didn't update
the on-disk metadata to match.

(I know it's possible, because I did this!)

Our normal mode of operation, of just saving the metadata during a
commit to match whatever's on-disk, would wipe out their careful
conflict resolution! (On the other hand, just overwriting the on-disk
metadata might not be the best idea either.)

But the point of a conflict is that the changes between two different
branches *can't* be resolved automatically, and requires manual
intervention. Given that situation, asking them to resolve the
difference manually seems to be the most obvious option.

Compare output is... just output. We shouldn't need to pass two "-q"
options to shut it up.

Likening the metastore MSG_* levels to syslog() LOG_* levels, MSG_DEBUG
works like LOG_DEBUG, and the WARNING/ERROR/CRITICAL also have similar
roles. That leaves MSG_NORMAL as the equivalent of LOG_INFO, and
MSG_QUIET as the equivalent of LOG_NOTICE.

LOG_NOTICE is documented as for "normal, but significant, condition"
which tracks what MSG_QUIET is for - things that aren't errors, but that
you want to know about even when you've asked for quiet.

Whereas the output of "compare" is just regular output. Finding a
difference isn't a significant condition - it's exactly what you've
asked it to look for.

This makes `metastore` more useful in scripts, just to check if it found
anything, in the same way as `diff` and `grep`.

Note that POSIX requires that EXIT_SUCCESS is 0, and EXIT_FAILURE is 1,
so I've defined EXIT_DIFFERENCES as 2 which, while different from the
values `diff` and `grep` use (1 for finding something, 2 for errors),
maintains a certain amount of backwards compatibility with previous
versions of metastore.

If you're storing metadata in a version control system with multiple
branches, mtime differences are going to produce a whole bunch of
conflicts that you likely don't care about. This allows you to not
save mtime and avoid those.

Note that we use a sentinel value of -1 for the mentry `mtimensec` field
to indicate this in the data, as all values of `mtime` are theoretically
valid, but `mtimensec` must always be between 0 and 999,999,999 in the
real world.

I'm not 100% sure about the mechanism for selecting this feature. The
legacy behaviour for metastore was to save mtimes in the metadata files,
but ignore them for compare/apply by default, with a `--mtime` option to
use the mtime data.

Keeping the legacy behaviour for backwards compatibility, but adding a
`--no-mtime` option to ignore mtimes when saving felt like a reasonable
way of making this happen, but something about it doesn't feel great.

Maybe I just didn't figure out how to make the documentation clear
enough.  ¯\_(ツ)_/¯

This ensures that the files are stable, and not subject to the order in
which the OS returns directory entries. This should prevent unnecessary
changes, and therefore unnecessary merge conflicts.