2fc46e1871 broke running ./git-annex test
when git-annex-shell is not in PATH from another install, and also
caused the wrong git-annex-shell to be tested.
Using a symlink made programPath return the .cabal/ directory where the
git-annex binary is, but git-annex-shell is not in that directory.
Changing to a hard link avoids that problem.
Sponsored-by: Dartmouth College's Datalad project
The patch that removed it did not break anything, since the strings it's
used on are all ASCII not unicode. But I like making sure to use
packString everywhere just in case the code later changes in a way that
needs it.
In aeson 2.0, Text has been replaced by the Key type and HashMap by the
KeyMap interface. Accomodating this required adding some CPP in order to
still be able to compile with aeson < 2.0. The required changes were:
* Prevent Key from being re-exported by Utilities.Aeson, as it clashes
with git-annex's own Key type.
* Fix up convertion from String/Text to Key (or Text in aeson 1.*) in a
couple of places
* Import Data.Aeson.KeyMap instead of Data.HashMap.Strict, as they are
mostly API-compatible. insertWith needs to be replaced by unionWith,
however, as KeyMap lacks the former function.
Avoid git-annex test being very slow when run from within the standalone
linux tarball or OSX app.
It may not really be necessary to add to PATH the directory where the
git-annex binary resides, but it can't hurt. Most places where the test
suite or git-annex run git-annex, they use programPath, so won't need
a modified PATH. But I'm not sure if that's always the case.
Sponsored-by: Dartmouth College's Datalad project
After ce91f10132, unannex on a non-annexed
file is expected to fail, unless annex.skipunknown were globally
overridden to true. So this test that used to succeed should probably
fail, but it seems better to just remove it than expect it to fail.
I cannot find any indication that git-annex uses these exit statuses,
and I see I didn't write this doc so I don't know where those numbers
came from. Odd.
Propagate nonzero exit status from git ls-files when a specified file does
not exist, or a specified directory does not contain any files checked into
git.
The recent completion of the annex.skipunknown transition exposed this
bug, that has unfortunately been lurking all along.
It is also possible that git ls-files errors out for some other reason
-- perhaps a permission problem -- and this will also fix error propagation
in such situations.
Sponsored-by: Dartmouth College's Datalad project
It did nothing, since at this point the link is dangling. But when there
is a thaw hook, it would probably not be happy to be asked to run on a
symlink, or might do something unexpected.
Sponsored-by: Dartmouth College's Datalad project
