Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
|
|
|
|
Only version 0 is supported here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously metastore would fail if running from / and paths were given:
$ pwd
/
$ metastore -d bin
lstat failed for .bin: No such file or directory
Now it works properly:
$ metastore -d bin | head -1
lrwxrwxrwx root root 2018-08-17 16:31:23.120322532 +0200 ./bin/hostname
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
|
|
|
|
|
|
|
|
|
Support building with no extended attributes support when NO_XATTR
macro is predefined to non-0 value (e.g. put -DNO_XATTR in CFLAGS).
|
|
|
|
|
|
Also change level of usage message shown after critical one to error,
so it can be suppressed without hiding critical one if desired (-qqq).
|
|
README is actually written in markdown, but I don't like .md extension.
README.md is here only for better experience of web viewers of the repo,
it's set to be not exported by git archive and won't be present in
released tarballs.
BTW if GitHub is offline, you can use following unofficial mirror:
http://repo.or.cz/metastore.git
(It also renders README.md file, that's why I mentioned it here.)
|
|
|
|
The Software Package Data Exchange (SPDX) is a good initiative, it has
matured over time and deserves accelerated adoption in open-source.
https://spdx.org/learn
https://spdx.org/using-spdx
https://spdx.org/license-list
|
|
Reformat second paragraph for better look. It had awkward line wrap.
Modernize third paragraph. No need to send letters to FSF in Boston.
|
|
David misdocumented read/write int functions back in commit
5fed2f9169fdd0585cc83ff0fa8210d97da77cb2 (2007-05-19) and later it
probably got copy-pasted to the documentation of file format.
|
|
Avoid using VLAs when it is not really needed, especially in cases like
this one here, when possible array size is very limited (1-8 bytes).
|
|
Declare file-scope objects or functions that do not need external
linkage as static.
|
|
Explicitly specify void when a function accepts no arguments.
|
|
|
|
|
|
See commit 16cde6c32fb3e0640ac01ca5d8ddea127f59106c for details.
|
|
|
|
PATH_MAX is not guaranteed by POSIX to be present and some systems, like
GNU Hurd, indeed does not define it.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html
For now let's define PATH_MAX as 4096 (if it is not already defined),
because that's how Linux defines it and it seems quite reasonable.
In future dependence on PATH_MAX can be removed.
|
|
|
|
https://bugs.debian.org/883539
Requested-by: Romain Francoise <rfrancoise@debian.org>
|
|
|
|
|
|
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
|
Wrong type has been used for calculating size of requested memory.
Underallocation happened in mentries_fromfile() code path if
sizeof(ssize_t) > sizeof(int), which is true on 64-bit platforms.
Reading metadata file with extended attributes entries led to corruption
of metadata represented in memory on such platforms, so applying could
led to corruption of metadata on disk too.
Reported-by: Uros Juvan <asmpro@gmail.com>
|
|
That way we can avoid possible (yet not feasible in current code)
NULL pointer dereference.
|