Repository navigation
git-filesync 0.20.1
Nothing in the way of a linked file is deleted; review fixes
Changes:
- Something in the way of a linked file - a directory (or anything else
but a file) where the file belongs, a parent directory that is a file,
or a path through a symbolic link - is now an error: status reports it,
and restore, pull, rm and mv refuse to touch it ("move it away, or
remove the link with 'git filesync unlink FILE'"). Before, such a
directory counted as a missing file, and restore or pull deleted it with
all in it. - pull --all names the files it leaves alone that need attention -
missing, or modified but not adaptable - instead of saying "everything
up to date" (exit code unchanged). - A link whose recorded commit no longer exists upstream (history
rewritten there) is shown as 'changed (previous sync point unknown)',
and pull records the current commit, also if the file itself is the
same. Likewise, pull --commit REV records REV's commit when the file is
the same there. - The first sync of a new link (an entry without commit and blob) shows
the warnings of any pull (e.g. a commit not pushed in a mapped
checkout); pull -n names a --commit, -b or --tag given for it. Like add,
it stages the file as it is in the working tree, uncommitted changes
included (--overwrite: replaced, the content kept as a blob). - add refuses an existing file that can't be compared with the upstream
version (e.g. not readable from the cache) instead of taking it for
unmodified. - .git-filesync with keys on a section's header line: changes are written
with git config instead of adding a second section of the same name. - Fewer git calls for files not committed yet and for the first sync of
many new links.
Documentation:
- MANUAL: paths something is in the way of; pull --all and files that need
attention; rewritten upstream history; the first sync of a new link;
pull --commit for any number of files; how the newest tag is found;
exit code table. - Pinned example versions in README and MANUAL set to v0.20.1.