allow building with aeson >= 2.0

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.

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

add

Added a comment

git-annex test from standalone speedup

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

update comment

comment

remove broken test

After ce91f10132805d11448896304821b0aa9c6d9845, 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.

Added a comment: question about backend

initial report on a very slow git annex test  on discovery

commet

Added a comment

Added a comment

update

open related todo

remove 127/128 exit status mention

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.

mention --size-limit effect on exit status

Documented elsewhere already.

fix annex.skipunknown false error propagation

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

comment

news

comment

initial report on changed (and non-conformant) behavior of  annex find

comment

turn of PackageImports in cabal file

This makes it easier to build eg benchmarks of individual modules.

May be that most of these PackageImports are not really necessary,
dunno.

avoid accidentally thawing git-annex symlink

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

Run annex.thawcontent-command before deleting an object file

In case annex.freezecontent-command did something that would prevent
deletion.

Sponsored-by: Dartmouth College's Datalad project

add debugging of freeze and thaw

ignore write bits being set when there is a freeze hook

When annex.freezecontent-command is set, and the filesystem does not
support removing write bits, avoid treating it as a crippled filesystem.

The hook may be enough to prevent writing on its own, and some filesystems
ignore attempts to remove write bits.

Sponsored-by: Dartmouth College's Datalad project

comment

comment

comment

Added a comment

Added a comment: for some reason `drop` freezes thawn key file before thawing key dir

Added a comment: approach which somewhat works

adjusted with edit 1 observation

initial experimentation/complain about freeze/thawing files

smudge: Warn when encountering a pointer file that has other content appended to it

It will then proceed to add the file the same as if it were any other
file containing possibly annexable content. Usually the file is one that
was annexed before, so the new, probably corrupt content will also be added
to the annex. If the file was not annexed before, the content will be added
to git.

It's not possible for the smudge filter to throw an error here, because
git then just adds the file to git anyway.

Sponsored-by: Dartmouth College's Datalad project

fully specify the pointer file format

This format is designed to detect accidental appends, while having some
room for future expansion.

Detect when an unlocked file whose content is not present has gotten some
other content appended to it, and avoid treating it as a pointer file, so
that appended content will not be checked into git, but will be annexed
like any other file.

Dropped the max size of a pointer file down to 32kb, it was around 80 kb,
but without any good reason and certianly there are no valid pointer files
anywhere that are larger than 8kb, because it's just been specified what it
means for a pointer file with additional data even looks like.

I assume 32kb will be good enough for anyone. ;-) Really though, it needs
to be some smallish number, because that much of a file in git gets read
into memory when eg, catting pointer files. And since we have no use cases
for the extra lines of a pointer file yet, except possibly to add
some human-visible explanation that it is a git-annex pointer file, 32k
seems as reasonable an arbitrary number as anything. Increasing it would be
possible, eg to 64k, as long as users of such jumbo pointer files didn't
mind upgrading all their git-annex installations to one that supports the
new larger size.

Sponsored-by: Dartmouth College's Datalad project

read up to and including maxPointerSz

For consistency with everything else.

Sponsored-by: Dartmouth College's Datalad project

read a consistent amount from pointer file

A few places were reading the max symlink size of a pointer file,
then passing tp parseLinkTargetOrPointer. Which is fine currently, but
to support pointer files with lines of data after the pointer, enough
has to be read that parseLinkTargetOrPointer can be assured of seeing
enough of that data to know if it's correctly formatted.

Sponsored-by: Dartmouth College's Datalad project

fold parseLinkTarget into parseLinkTargetOrPointer

Only one place remained that differentiated between them.

It is the case that a symlink target that happens to contain a newline
somehow will be treated as a link to a key truncated at the newline.
This is super unlikely to happen, and since a key cannot actually
contain a newline, it's as good a behavior as any. Anyway, this commit
does not change the behavior there, although arguably it should be
changed. Note that getAnnexLinkTarget does prevent a symlink target
containing a newline.

Sponsored-by: Dartmouth College's Datalad project

comment

Added a comment: inodes of git vs. git-annex

add news item for git-annex 10.20220222

releasing package git-annex version 10.20220222

comment

Added a comment

Added a comment

Added a comment

comment

comment

comment and close, not a bug really

comment

comment

info: Allow using matching options in more situations

File matching options like --include will be rejected in situations where
there is no filename to match against. (Or where there is a filename but
it's not relative to the cwd, or otherwise seemed too bothersome to match
against.)

The addition of listKeys' was necessary to avoid using more memory in the
common case of "git-annex info". Adding a filterM would have caused the
list to buffer in memory and not stream. This is an ugly hack, but listKeys
had previously run Annex operations inside unafeInterleaveIO (for direct
mode). And matching against a matcher should hopefully not change any Annex
state.

This does allow for eg `git-annex info somefile --include=*.ext`
although why someone would want to do that I don't really know. But it
seems to make sense to allow it.
But, consider: `git-annex info ./somefile --include=somefile`
This does not match, so will not display info about somefile.
If the user really wants to, they can `--include=./somefile`.

Using matching options like --copies or --in=remote seems likely to be
slower than git-annex find with those options, because unlike such
commands, info does not have optimised streaming through the matcher.

Note that `git-annex info remote` is not the same as
`git-annex info --in remote`. The former shows info about all files in
the remote. The latter shows local keys that are also in that remote.
The output should make that clear, but this still seems like a point
where users could get confused.

Sponsored-by: Jochen Bartl on Patreon

comment

retitle

Added a comment

removed

Added a comment: free dweb storage services

Added a comment: free dweb storage services

Added a comment

Added a comment

Added a comment

initial thinking for a possible safe guard

bug/question on the semantic of find --unlocked

Avoid git status taking a long time after git-annex unlock of many files.

Implemented by making Git.Queue have a FlushAction, which can accumulate
along with another action on files, and runs only once the other action has
run.

This lets git-annex unlock queue up git update-index actions, without
conflicting with the restagePointerFiles FlushActions.

In a repository with filter-process enabled, git-annex unlock will
often not take any more time than before, though it may when the files are
large. Either way, it should always slow down less than git-annex status
speeds up.

When filter-process is not enabled, git-annex unlock will slow down as much
as git status speeds up.

Sponsored-by: Jochen Bartl on Patreon

restage pointer file after unlock

This avoids a later git status or similar taking a long time to run
as it runs git-annex smudge once per file. While v9 repositories do
avoid that taking long when the files are small, large files can still
make git status take a very long time.

This does make unlock slower, because now git-annex smudge is being run
once per file unlocked. However, the next commit should speed that up in
many cases.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

complete annex.skipunknown transition

annex.skipunknown now defaults to false, so commands like `git annex get foo*`
will not silently skip over files/dirs that are not checked into git.

Sponsored-by: Brock Spratlen on Patreon

comment

comment

comment

Added a comment: I have the same problem

registerurl,unregisterurl: rework output and support --json

* registerurl, unregisterurl: Improved output when reading from stdin
  to be more like other batch commands.
* registerurl, unregisterurl: Added --json and --json-error-messages options.

Note that this did change the --batch output in a way that could possibly
break something that expected the old output to never change. I think it's
acceptable to break that because there has never been a guarantee of
unchanging output format except with --batch for most commands. The old
output was just really weird too!

One possible wart is that "git-annex registerurl" with no options now
seems to just hang, since it's waiting for stdin input. Before, it said
"registerurl (stdin)" which was clearer about what's happenening. But this
is a deprecated mode anyway, --batch makes clear what's happening. If
anything, this problem would be a reason to eventually remove the support
for reading from stdin w/o --batch.

Sponsored-by: Dartmouth College's Datalad project

comment

comment

initial report on a failing test

initial todo for --json for registerurl

Added a comment

comment

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

comment

close wontfix

document another behavior of --auto

add a test case for transition propagation

As was fixed in 6992250d63484a6cf3e5d22b9137d23a3fe1a63e.
It took 2-3 years to notice that bug, so this part of git-annex needs
test cases like this.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

fix obviously wrong attoparsec parser

takeByteString can only be used at the end of a parser, not before other
input. This was a dumb enough mistake that I audited the rest of the
code base for similar mistakes. Pity that attoparsec cannot avoid it at
the type level.

Fixes git-annex forget propagation between repositories. (reversion
introduced in version 7.20190122)

Sponsored-by: Brock Spratlen on Patreon

bug report followup

comment

comment