got configure working after Utility.Path ByteString conversion

Had to split out some modules because getWorkingDirectory needs unix,
which is not a build-dep of configure.

This commit was sponsored by Brock Spratlen on Patreon.

convert to RawByteString

This will break a lot of stuff that uses it, but once fixed should lead
to better performance.

Mostly mechanical.
Changes of note:

* upFrom now uses isPathSeparator, which is better on Windows where
  there is not just one
* splitShortExtensions used to take the length of a string,
  which would count wide unicode characters as a single character.
  Changing to B.length changes that. Note that, git-annex's
  annexMaxExtensionLength already changed to the length in bytes
  before this change. This function is only used in generating views,
  and the small behavior change should not be a problem.
* relHome still uses FilePath because it didn't seem worth changing(?)

This commit was sponsored by Jack Hill on Patreon.

note windows versions the builds will work with

comment

Merge branch 'master' of ssh://git-annex.branchable.com

test if magic library works

(When built with it.)

I saw John Thorvald Wodder II doing this in
https://github.com/datalad/datalad-extensions/blob/master/.github/workflows/build-git-annex-windows.yaml
and it seemed like a good idea.

John used an empty file for the binary file, but I think it's
slightly suprising file picks that mime type for it, so opted to instead
use something less ambiguous.

Added a comment: Documentation of demand

Added a comment

view: Avoid using ':' from metadata when generating a view

Because it's a special character on Windows ("c:").

Use same technique already used for '/' and '\'.

I didn't record how I generated their encoded forms before, so am sure
there was a better way, but the way I did it now is to look at

ghci> encodeFilePath "∕"
"\226\136\149"

And then the difference from that to "\56546\56456\56469"
is adding 56320 to each, to get up to the escaped code plane.

See comment for why I think handling ':' is ok, but that other illegal
windows filenames won't. Note that, this should be enough to make the
test suite always work. Other windows illegal filenames will fail at
checkout time when it tries to put the illegal filename on the
filesystem.

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

fix build and add build example

changelog

make windows installer builder include libmagic files when present, but skip otherwise

allow magicmime on windows

John Thorvald Wodder II got it working using
https://github.com/datalad/file-windows so don't hard-disable it.

The stack.yaml still disables this build flag, because it needs an extra
C library to be installed, which stack cannot automate.

include libmagic in windows installer

This is from https://raw.githubusercontent.com/datalad/datalad-extensions/master/resources/git-annex-magicBundle.patch
which was written by John Thorvald Wodder II.

I have converted line endings from windows, and fixed indentation to use
tabs.

Windows build changed to one done by the datalad-extensions project using Github actions

This is a cleaner build than on Jenkins because the whole environment setup
is handled by the CI config, at least up to the point of "get a random bag
of Windows bytes".

Also, the Jenkins autobuilder has been intermittently failing for a long
time, not due to any problem with git-annex but just a failure to clean up
directories.

Also, this build runs the test suite, and it is (mostly) passing. Test
suite always failed in the jenkins environment.

Also, this build includes libmagic.

Here is the build workflow used by github actions:
https://github.com/datalad/datalad-extensions/blob/master/.github/workflows/build-git-annex-windows.yaml
The libmagic build has its own workflow:
https://github.com/datalad/file-windows/blob/master/.github/workflows/build.yml

(Also cleaned up some windows build cruft I don't use anymore.)

There is no build-version file to link to. I've opened a todo requesting
one: https://github.com/datalad/datalad-extensions/issues/55

comment

close

Added a comment: thanks

Merge branch 'master' of ssh://git-annex.branchable.com

document version for --force-large/--force-small

also fix the wrong name in the changelog

improve wording

initial report on a failing test

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment: where to trace the Windows build errors?

Merge branch 'master' of ssh://git-annex.branchable.com

Added a comment

Added a comment

Added a comment

remove dead links to youtube-dl

Presumably most users will get it from their linux distribution, or
whatever. Don't want to need to keep updating links if they're going to
rot like this.

use removeDirGeneric here too for consistency

And because it might be more robust on windows.

Revert "pass --git-dir, rather than changing cwd"

This reverts commit c142696c587100b195accec4e9bfaa26cde73d48.

It turns out it was not needed; 681313dfd4e840e6366f3c39eddd92f65d764188
fixed up the git dir, so setting cwd to it works ok.

But worst, this commit broke the test suite massively. I don't understand how.
git-annex get was failing. Very weirdly, git-annex find in a fresh
clone of an annex repo, during autoinit, was displaying a side message
-- but side messages are disabled when running find.

testremote: Display exceptions when tests fail, to aid debugging

deal with .git pointer file in Git.CurrentRepo

This fixes the bug.

Note, it's only done when GIT_DIR is set. When it's not set,
Git.Construct already handled it. This is why it was only noticed with this
git submodule command.

This commit was sponsored by Brett Eisenberg on Patreon.

comment

analysis

close

pass --git-dir, rather than changing cwd

If .git is a gitlink file, setting cwd to it will fail, but --git-dir
will succeed. And this is the only place where it sets cwd when running
git, everywhere else already uses --git-dir.

Note that, git-annex's submodule fixup code usually converts gitlink
files to symlinks, so this wasn't usually problem. Still, worth fixing.

This commit was sponsored by Svenne Krap on Patreon.

Merge remote-tracking branch 'origin/master'

analysis

Added a comment

Fix bug that prevented linux standalone bundle from working on a fresh install

Bug was introduced in version 8.20201007, lost a necessary mkdir.

This commit was sponsored by Noam Kremen on Patreon.

Added a comment

Added a comment

initial report on a failing test on windows about storeKey when already present

this protocol is not draft for some time

turns out this was fixed in 2014

Merge branch 'master' of ssh://git-annex.branchable.com

urk

Added a comment: windows build with magic

Added a comment

rename to avoid windows stupididy about legal filenames

add

add

update chunk log after speculated chunks are verified to be present

Only done in checkPresentChunks, although retrieveChunks could also do
it. Does not seem necessary though, because git-annex never retrives
content without first checking if it's present AFAICR. And really this will
only be needed when using fsck. Puttting it here, rather than in fsck
avoids breaking an abstraction boundary, and is nice and inexpensive.

speculatively use remote's configured chunk size as a fallback

When a special remote has chunking enabled, but no chunk sizes are
recorded (or the recorded ones are not found), speculatively try chunks
using the configured chunk size.

This makes eg, git-annex fsck --from remote be able to fix up the
location log of a file that the git-annex branch does not indicate is
stored on the remote.

Note that fsck does *not* fix up the chunk log to indicate the chunk
size. So, changing the chunk config of the remote after that will still
prevent accessing the chunks stored on it. Maybe fsck should, but I
wanted to start with this and see if it's needed.

close

Added a comment: cannot find this mentioned Windows build :|

Fix a broken link

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

move: Improve resuming a move that was interrupted after the object was transferred

In cases where numcopies checks prevented the resumed move from dropping
the object from the source repository, it now relies on a log of recent
moves to replicate the behavior of the interrupted command.

Performance: Probably noticable impact, since it has to add to the log,
check the log, and remove from the log. Seems worth it to avoid this
annoying edge case. The log functions are pretty well optimised to avoid
unncessary work.

An performance improvement to make later would be to avoid cleanup doing
anything if it's not written to the log file, and has confirmed that the
log file does not contain the log line.

This commit was sponsored by Jake Vosloo on Patreon.

removed

Added a comment

Added a comment

report/idea on minting chunked keys to try from special remote

more log file actions

Which will be needed soon.

And use more ByteStrings for speed.

This commit was sponsored by Graham Spencer on Patreon.

improve name

Added a comment

Added a comment

Added a comment

 New bug report

Added a comment

Added a comment

add, import: Fix a reversion in 7.20191009 that broke handling of --largerthan and --smallerthan

This commit was sponsored by Jochen Bartl on Patreon.

bug

comment

Merge branch 'master' of ssh://git-annex.branchable.com into master

design done

update

fix build warning

more thoughts

don't try to remove pre-commit-annex and post-update-annex-hooks

Those are not installed by git-annex but by the user, and so removal
will never find the default content, and so if the user did install
them, it would display a misleading message.

Seems better, since the user installed them, to let the user remove them
if they want to.

comment

comment

comment

Merge branch 'master' of ssh://git-annex.branchable.com into master

close

switch to Haskell2010

When I put in Haskell98 this spring, I was under the mistaken
apprehension that ghc defaulted to that. But it actually its default
is a third mode, which is closer to Haskell2010 but with some differences.
The manual says "By default, GHC mainly aims to behave (mostly) like a
Haskell 2010 compiler"

Fixed two cases where the Haskell98 do indentation flexability let
wrongly indented code build. That is one of the places where
ghc does not behave like Haskell2010 by default.

The other place that I think I was concerned about, is GHC manual
section 19.1.1.3. Expressions and patterns. But that only seems to
affect code using bottoms, so would only affect pure functions throwing
an error, which I don't think git-annex does in many places as it's
pretty horrid style. And it would only affect rare cases like shown in
that section. If it did happen, it would mean that the error was not
thrown before specifying Haskell98, and then was. Haskell2010 behaves
the same as Haskell98.

This commit was sponsored by Denis Dzyubenko on Patreon.

Added a comment: copying directly from directory special remote to the cloud

Added a comment: building the standalone distribution on CentOS

Added a comment