Note the use of git tag -f, this way if it takes several tries to get a
release published, it will use the final one for the tag.
Tags have been retrospectively added for past releases, using this:
for v in $(git log --oneline --grep="publishing git-annex "| sed 's/ publishing git-annex / /'); do foo=$(echo "$v" | sed 's/ .*//'); bar=$(echo "$v" | sed 's/.* //'); git tag git-annex_"$bar" "$foo" ; done
This is groundwork for setting the close-on-exec flag when opening
files, which will be done in Utility.FileIO or a similar module using the same
function names. The bytestring library does not set that flag, even though it
could, and IMHO should.
Note that there are many calls to the Prelude's readFile/writeFile/appendFile
still in git-annex, and this does not address those.
Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project
Which fixed an OOM with unlocked files.
Debian oldoldstable is the oldest version of git that git-annex needs to
support, since it's used in the amd64ancient build. That has 2.30.
At this point, the only complication git-annex for an bug in old
versions of git is that git bundle was broken before git 2.31.
That prevents git-remote-annex from working with git 2.30.
Sponsored-by: Luke T. Shumaker
This entirely removes Git.BuildVersion, which avoids the possibility that
git-annex will behave differently based on the version of git it was built
with, rather than the version it's used with.
Debian oldoldstable is the oldest version of git that git-annex needs to
support, since it's used in the amd64ancient build.
cabal configure will fail if the git version is too old.
Sponsored-by: Nicholas Golder-Manning
Added git-remote-p2p-annex, which allows git pull and push to P2P networks
provided by external commands.
This is a refactor of git-remote-tor-annex, and should just work. Except
possibly for quirks with the address parsing. I've checked that the address
parsing basically works.
One thing I don't understand is why git-remote-tor-annex removes "/*" from
the end of the address. The git history does not provide any hints. So I
didn't make git-remote-p2p-annex do the same. Maybe that is needed in some
situation? But, a P2P address could contain "/", so removing it would be a
problem. I can't see anything in gitremote-helpers(7) about why the url
might get such a thing added to the end of it. My guess is that is not
needed for tor either (but does no harm there since onion addresses never
contain "/").
At this point, the implementation of generic P2P transports needs only
remotedaemon support.
I hope that the windows test suite failure on appveyor was fixed by
updating to a newer windows there. I have not been able to reproduce
that failure in a windows 11 VM run locally.
Taking a ShortByteString and using OverloadedStrings should avoid it
being converted from a String.
The reason there is no IsString instance for OsPath is presumably the
bad behavior of IsString for ByteString on unicode btw. But
literalOsPath won't be used with unicode in git-annex.
Sponsored-by: unqueued
It seems to make sense to convert both System.Directory and
System.FilePath uses to OsPath in one go. This will generally look like
replacing RawFilePath with OsPath in type signatures, and will be driven
by the now absolutely massive pile of compile errors.
Got a few modules building in this new regime.
Sponsored-by: Jack Hill
By using System.Directory.OsPath, which takes and returns OsString,
which is a ShortByteString. So, things like dirContents currently have the
overhead of copying that to a ByteString, but that should be less than
the overhead of using Strings which often in turn were converted to
RawFilePaths.
Added Utility.OsString and the OsString build flag. That flag is turned
on in the stack.yaml, and will be turned on automatically by cabal when
built with new enough libraries. The stack.yaml change is a bit ugly,
and that could be reverted for now if it causes any problems.
Note that Utility.OsString.toOsString on windows is avoiding only a
check of encoding that is documented as being unlikely to fail. I don't
think it can fail in git-annex; if it could, git-annex didn't contain
such an encoding check before, so at worst that should be a wash.
* Removed the i386ancient standalone tarball build for linux, which
was increasingly unable to support new git-annex features.
* Removed support for building with ghc older than 9.0.2,
and with older versions of haskell libraries than are in current Debian
stable.
* stack.yaml: Update to lts-23.2.
Note that i386ancient was targeting linux 2.6.32, which has been EOL for
over 9 years now. Any old system still using such a kernel is certainly highly
insecure. And I suspect i386ancient had its own insecurities due to haskell
libraries and C libraries not having been updated.
New curl binary links to libldap with a @loader_path that prevents using
the binary when the dmg is used elsewhere.
See https://github.com/datalad/git-annex/issues/170
git-annex doesn't use curl by default anyway, so it doesn't really need to
be included in the dmg.
Fix behavior when importing a tree from a directory remote when the
directory does not exist. An empty tree was imported, rather than the
import failing. Merging that tree would delete every file in the
branch, if those files had been exported to the directory before.
The problem was that dirContentsRecursive returned [] when the directory
did not exist. Better for it to throw an exception. But in commit
74f0d67aa3 back in 2012, I made it never
theow exceptions, because exceptions throw inside unsafeInterleaveIO become
untrappable when the list is being traversed.
So, changed it to list the contents of the directory before entering
unsafeInterleaveIO. So exceptions are thrown for the directory. But still
not if it's unable to list the contents of a subdirectory. That's less of a
problem, because the subdirectory does exist (or if not, it got removed
after being listed, and it's ok to not include it in the list). A
subdirectory that has permissions that don't allow listing it will have its
contents omitted from the list still.
(Might be better to have it return a type that includes indications of
errors listing contents of subdirectories?)
The rest of the changes are making callers of dirContentsRecursive
use emptyWhenDoesNotExist when they relied on the behavior of it not
throwing an exception when the directory does not exist. Note that
it's possible some callers of dirContentsRecursive that used to ignore
permissions problems listing a directory will now start throwing exceptions
on them.
The fix to the directory special remote consisted of not making its
call in listImportableContentsM use emptyWhenDoesNotExist. So it will
throw an exception as desired.
Sponsored-by: Joshua Antonishen on Patreon
POSIX character classes allowed in globs was a surprise, but just
happened to fall out of the implementation in a way that seems
to behave correctly.
mdwn2man has to be tweaked to render the example properly.
The line I modified is the one that strips ikiwiki wikilinks out of the
man page.
Sponsored-by: Graham Spencer on Patreon
Added arm64 build for ancient kernels, needed to support Android phones
whose kernels are too old to support kernels used by the current arm64
build.
Updated Android/git-annex-install to use it. (Also made it use i386-ancient
because that seems like a good idea.)
Sponsored-by: Noam Kremen on Patreon
Works around this bug in unix-compat:
https://github.com/jacobstanley/unix-compat/issues/56
getFileStatus and other FilePath using functions in unix-compat do not do
UNC conversion on Windows.
Made Utility.RawFilePath use convertToWindowsNativeNamespace to do the
necessary conversion on windows to support long filenames.
Audited all imports of System.PosixCompat.Files to make sure that no
functions that operate on FilePath were imported from it. Instead, use
the equvilants from Utility.RawFilePath. In particular the
re-export of that module in Common had to be removed, which led to lots
of other changes throughout the code.
The changes to Build.Configure, Build.DesktopFile, and Build.TestConfig
make Utility.Directory not be needed to build setup. And so let it use
Utility.RawFilePath, which depends on unix, which cannot be in
setup-depends.
Sponsored-by: Dartmouth College's Datalad project
This does mean it has to run ldd once per executable, which is actually
quite a number of times, so will be a bit slower.
Sponsored-by: Luke Shumaker on Patreon
