remove

comment

comment

multicast: Support uftp 5.0 by switching from aes256-cbc to aes256-gcm

aes256-gcm is supported by both 4.x and 5.x, while 5.x dropped aes256-cbc.

Sponsored-by: Graham Spencer on Patreon

comment

Added a comment

report on cryto test FAIL on NFS

Added a comment: new backends

Describe compatibility bug with uftp 5.0

Added a comment: The man page export seems to be broken

Added a comment

Added a comment: Myself

Added a comment: recording state in git

Added a comment: Discrepancy between `git add` and `git annex add` when annex.largefiles is set

Added a comment: Improving on the WORM situation

todo

todo

Added a comment: maxextensionlength

add easy-git-annex to related_software

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

how to implement this?

add a link to git-annex-dead

comment

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

update

Added a comment

todo triage

Tagging todos that seem to have a plan ready as confirmed.

Also closed some old ones for various reasons. Including several that
turn out to be addressed by newer features.

Also opened a new todo about git-annex-config needing a criteria to add
new configs to it.

comment

comment

commnet

Added a comment: TL;DR

Added a comment: Inode rotation on android /sdcard

Added a comment

assistant prompt pushing of manual commits to remotes

assistant: When annex.autocommit is set, notice commits that the user makes
manually, and push them out to remotes promptly.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

Added a comment

comment

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

more thoughts

This idea seems fleshed out enough to implement now.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon

idea

Added a comment

Added a comment: No bueno

idea

improve documentation of overridding git-annex config with gitconfig

comment

retitle

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

prevent numcopies or mincopies being configured to 0

Ignore annex.numcopies set to 0 in gitattributes or git config, or by
git-annex numcopies or by --numcopies, since that configuration would make
git-annex easily lose data. Same for mincopies.

This is a continuation of the work to make data only be able to be lost
when --force is used. It earlier led to the --trust option being disabled,
and similar reasoning applies here.

Most numcopies configs had docs that strongly discouraged setting it to 0
anyway. And I can't imagine a use case for setting to 0. Not that there
might not be one, but it's just so far from the intended use case of
git-annex, of managing and storing your data, that it does not seem like
it makes sense to cater to such a hypothetical use case, where any
git-annex drop can lose your data at any time.

Using a smart constructor makes sure every place avoids 0. Note that this
does mean that NumCopies is for the configured desired values, and not the
actual existing number of copies, which of course can be 0. The name
configuredNumCopies is used to make that clear.

Sponsored-by: Brock Spratlen on Patreon

switch from hothasktags to hasktags

hothasktags was removed from Debian. And in the meantime hasktags
improved so it works well in the source tree.

Also make dev update tags.

Sponsored-by: Jack Hill on Patreon

add news item for git-annex 10.20220322

releasing package git-annex version 10.20220322

fix quickcheck test on windows

prop_relPathDirToFileAbs_basics (TestableFilePath ":/") failed on
windows. The colon was filtered out after trying to make
the path relative, which only removed leading path separators.
So, ":/" changed to "/" which is not relative. Filtering out the colon
before hand avoids this problem.

Sponsored-by: Luke Shumaker on Patreon

prop_relPathDirToFileAbs_basics has another hickup again in QuickChecks

remove copyright entry for removed vendored library

Removed the NetworkBSD build flag

Debian stable and the i386ancient build both have a new enough network
to not need this flag any longer.

Sponsored-by: Svenne Krap on Patreon

remove vendored http-client-restricted

Removed vendored copy of http-client-restricted, and removed the
HttpClientRestricted build flag that avoided that dependency.

http-client-restricted is in Debian stable, and the i386ancient build also
uses it, so I think this vendored copy is no longer needed.

Sponsored-by: Noam Kremen on Patreon

bump i386ancient deps to allow using http-client-restricted and git-lfs

This should let i386ancient limp along for a few years more, beyond the
removal of those vendored deps from git-annex.

Also networkbsd is set now, so probably the last thing to unset that
flag is gone, and the flag could be removed soon.

Sponsored-by: Jarkko Kniivilä on Patreon

relax enough i386ancient deps to allow new tasty

The new ansi-terminal was needed for test concurrency, and the new
concurrent-output fixes several bugs. And it turns out this is all
that's needed to use the new tasty.

Sponsored-by: Kevin Mueller on Patreon

re-relax tasty dependency version for i386ancient build

Dependency issues were looking difficult to support tasty-1.2 with that
build. Not using `after` only affects rerunning and limiting tests,
since tasty's concurrency is not used, so this build will just not
support that.

We are probably nearing end of life on this build; it also doesn't
support git-lfs or http-client-restricted. The 2.6.32 kernel it supports
is at this point 13 years old, and stopped being supported by linux LTS
developers 10 years ago. It was supported by RHEL 6.10 through November
2020. At this point, no new hardware should be shipping with this
kernel, but that probably does not stop certian embedded vendors from
shipping it. And there is certainly some hardware still using it. But
the returns from supporting it are diminishing, and the quality of the
build for it is also diminishing.

Sponsored-by: Nicholas Golder-Manning on Patreon

bump ansi-terminal for tastyversion bump

update tasty version to new minimum

reorder

comment

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

fix reversion

add: Avoid unncessarily converting a newly unlocked file to be stored
in git when it is not modified, even when annex.largefiles does not
match it.

This fixes a reversion in version 10.20220222, where git-annex unlock
followed by git-annex add, followed by git commit file could result in
git thinking the file was modified after the commit.

I do have half a mind to remove the withUnmodifiedUnlockedPointers part
of git-annex add. It seems weird, despite that old bug report arguing
a case of consistency that it ought to behave that way. When git-annex
add surpises me, it seems likely it's wrong.. But for now, this is the
smallest possible fix.

Sponsored-by: Dartmouth College's Datalad project

Added a comment

Added a comment

comment

diagnose user error

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

add back inode to directory special remote ContentIdentifier

Directory special remotes with importtree=yes have changed to once more
take inodes into account. This will cause extra work when importing from a
directory on a FAT filesystem that changes inodes on every mount.

To avoid that extra work, set ignoreinodes=yes when initializing a new
directory special remote, or change the configuration of your existing
remote: git-annex enableremote foo ignoreinodes=yes

This will mean a one-time re-import of all contents from every directory
special remote due to the changed setting.

73df633a6215faa093e4a7524c6d328aa988aed1 thought
it was too unlikely that there would be modifications that the inode number
was needed to notice. That was probably right; it's very unlikely that a
file will get modified and end up with the same size and mtime as before.
But, what was not considered is that a program like NextCloud might write
two files with different content so closely together that they share the
mtime. The inode is necessary to detect that situation.

Sponsored-by: Max Thoursie on Patreon

removed

Added a comment: Site Migration Issue Faced

Created

Added a comment

Added a comment

Added a comment

comment

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

test: Added --jobs option

Default to the number of CPU cores, which seems about optimal
on my laptop. Using one more saves me 2 seconds actually.

Better packing of workers improves speed significantly.

In 2 tests runs, I saw segfaulting workers despite my attempt
to work around that issue. So detect when a worker does, and re-run it.

Removed installSignalHandlers again, because I was seeing an
error "lost signal due to full pipe", which I guess was somehow caused
by using it.

Sponsored-by: Dartmouth College's Datalad project

cleaner test dependencies

This improves the display of tests.

tasty-1.2 is in debian stable.

Sponsored-by: Dartmouth College's Datalad project

clean up concurrent output of tests

Using concurrent-output this is easy. Just have to check if tasty has
color enabled, and propagate it into the worker processes, some of which
will be run without a controlling console.

Also added a call to installSignalHandlers; I noticed that interrupting
the test suite could leave the console in a bad state and this fixes
that.

The ansi-terminal dependency is free, since tasty also depends on it.

Sponsored-by: Dartmouth College's Datalad project

Added a comment: I have seen this

Added a comment: FWIW a detail

link to issue for tasty segfault

allow tests to be split for more granularity

Unit tests are the main bulk of runtime, so splitting them into 2 or 3
parts should help.

For now, the number of parts is still 1, because on my 4 core laptop,
2 was a little bit slower, and 3 slower yet. However, this probably does
vary based on the number of cores, so needs to be revisited, and perhaps
made dynamic.

Since each test mode gets split into the specified number of parts,
plus property and remote tests, 2 gives 8 parts, and 3 gives 11 parts.
Load went to maybe 18, so there was probably contention slowing things
down.

So probably it needs to start N workers with some parts, and when a
worker finishes, run it with the next part, until all parts are
processed.

Sponsored-by: Dartmouth College's Datalad project

parallelize git-annex test for 25% speedup

Note the very weird workaround for what appears to be some kind of tasty
bug, which causes a segfault. This is not new to this modification,
I was seeing a segfault before at least intermittently when limiting
git-annex test -p to only run a single test group.

Also, the path from one test repo to a remote test repo used to be
"../../foo", which somehow broke when moving the test repos from .t to
.t/N. I don't actually quite understand how it used to work, but
"../foo" seems correct and works in the new situation.

Test output from the concurrent processes is not yet serialized.
Should be easy to do using concurrent-output.

More test groups will probably make the speedup larger. It would
probably be best to have a larger number of test groups and divvy them
amoung subprocesses numbered based on the number of CPU cores, perhaps
times 2 or 3.

Sponsored-by: Dartmouth College's Datalad project

fix accidental change to Test.hs while making comment

indentation

Added a comment