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

fix build warning

Added a comment

S3 region=

S3: Support a region= configuration useful for some non-Amazon S3
implementations. This feature needs git-annex to be built with aws-0.24.

datacenter= sets both the AWS hostname and region in one setting, which is
easy when using AWS, but not useful for other hosts. So kept datacenter
as-is, but added this additional config.

Sponsored-By: Brett Eisenberg on Patreon

comment

comment

Added a comment

Added a comment: 👍 +1 for updating the view when committing

Added a comment

Added a comment

Added a comment: same error, same fix

Added a comment

analysis

correct obsolete comment

comment

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

ignore git-annex-build-deps files from dpkg-genbuilddeps

The autobuilders run that in the git-annex tree, and the command
does not clean up after itself.

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

work around ldd crash on arm64 autobuilder

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

Added a comment

Added a comment: file:/// must be forced to file:// on windows

support old libgcc1 name

Used in Debian jessie, which the i386ancient autobuilder uses.

add upper bounds on base version

hackage now rejects packages without this

add upper bounds on Cabal version

hackage now rejects packages without this. My bet is any version of
cabal is going to work, I'm using the public API. Annoying.

add news item for git-annex 10.20230126

releasing package git-annex version 10.20230126

new linux autobuilder

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

remove libghc-pcre-light-dev build dep

Unused build dep.

Also updated some other deps based on debian's fork of this file.

Added a comment: thanks

Added a comment: Thank you!!

improve wording

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

use transfer stages for copy --from

See commit e04a9314392037e7b54a098f9709fc6040327411 for an explanation
of why move uses transfer stages for --from, but command stages for
--to. At the point of that commit, copy was actually already using
command stages for everything, so the commit was incorrect about
improving copy --to.

But, the same reasoning about --from applies to copy as to move; when
verification is not done incrementally, download and verification are
the main two stages. The cleanup stage for copy is even less work than
for move (it doesn't drop from the remote).

Sponsored-by: Dartmouth College's DANDI project

improve concurrency of move/copy --from --to

Use separate stages for download and upload. In the common case where
it downloads the file from one remote and then uploads to the other,
those are by far the most expensive operations, and there's a decent
chance the two remotes bottleneck on different resources.

Suppose it's being run with -J2 and a bunch of 10 mb files. Two threads
will be started both downloading from the src remote. They will probably
finish at the same time. Then two threads will be started uploading to
the dst remote. They will probably take the same time as well. Before
this change, it would alternate back and forth, bottlenecking on src and dst.
With this change, as soon as the two threads start uploading to dst, two
more threads are able to start, downloading from src. So bandwidth to
both remotes is saturated more often.

Other commands that use transferStages only send in one direction at a
time. So the worker threads for the other direction will sit idle, and
there will be no change in their behavior.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

Added a comment

Added a comment

update

Merge branch 'fromto'

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

done

fix behavior of copy --from --to

Sponsored-by: Dartmouth College's DANDI project

Merge branch 'master' into fromto

finishing up move --from --to

Lock the local content for drop after getting it from src, to prevent another
process from using the local content as a copy and dropping it from src,
which would prevent dropping the local content after sending it to dest.

Support resuming an interrupted move that downloaded the content from
src, leaving the local content populated. In this case, the location log
has not been updated to say the content is present locally, so we can
assume that it's resuming and go ahead and drop the local content after
sending it to dest.

Note that if a `git-annex get` is being ran at the same time as a
`git-annex move --from --to`, it may get a file just before the move
processes it. So the location log has not been updated yet, and the move
thinks it's resuming. Resulting in local copy being dropped after it's
sent to the dest. This race is something we'll just have to live with,
it seems.

I also gave up on the idea of checking if the location log had been updated
by a `git-annex get` that is ran at the same time. That wouldn't work, because
the location log is precached in the seek stage, so reading it again after
sending the content to dest would not notice changes made to it, unless the cache
were invalidated, which would slow it down a lot. That idea anyway was subject
to races where it would not detect the concurrent `git-annex get`.

So concurrent `git-annex get` will have results that may be surprising.
To make that less surprising, updated the documentation of this feature to
be explicit that it downloads content to the local repository
temporarily.

Sponsored-by: Dartmouth College's DANDI project

fully working move --from --to (not release quality)

When the destination already has a copy, it behaves the same as
drop --from really, but display it as a move and implement it
reusing the factored out code from fromPerform.

(Note that willDropMakeItWorse never returns DropAllowed in that
situation, because it's told that dest has a copy. So numcopies is
always checked.)

And when only the source and not the local repo or destination have a
copy, do the full copy from source to local, then copy from local to
dest, then drop from local, then drop from source dance.

This is complicated by fromPerform being hardcoded to assume there is a
local copy, but the local copy has already been dropped. That's why
it uses cleanupfromsrc RemoveNever to avoid the code that makes that
assumption, and finishes with a call to dropfromsrc.

And, since the location log has not yet been updated, checking numcopies
was not working, until I added UnVerifiedRemote dest to the list of
things to check.

This is not yet quite mergeable though. There are two things in the
comment above fromToPerform that are not implemented yet: Checking the
location log before dropping the local copy, and locking the temporary
local copy for drop.

Sponsored-by: Dartmouth College's DANDI project

push location log updating up to callers of download

Prep for move --to --from, which needs to download from a src repo
without updating the location log for the local repo, before sending the
content on to the dest repo.

Note that caller of download' already update the log themselves.
See previous commit a422a056f2785999220cde55e07b0fbf999edd44
that pushed it up to download from getViaTmpFrom.

(Also removed in passing a debug print + readline that I accidentially
committed last week on this branch.)

Sponsored-by: Dartmouth College's DANDI project

implement move --from --to when there is a local copy already

This is rather trivial, since it does not need to temporarily get the
local copy.

Added fromPerform' to handle the situation where the local copy
is dropped by another process during the copy to the dest. This avoids
ever re-downloading the local copy before dropping from the src.

Sponsored-by: Dartmouth College's DANDI project

update

Fix typo in heading that seems to result in git-annex-drop not showing up in `man -k` output

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

comment

remove --fast from man page

git-annex move does not actually behave any differently with --fast than
without it. (git-annex copy does)

(cherry picked from commit f74904ee2c7cec936cac3f2536daa1d426739b80)

move/copy: started implementing --from src --to dest

This is not in a usable state, but I have a possible plan for how to do
it.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

Added a comment

Added a comment

remove --fast from man page

git-annex move does not actually behave any differently with --fast than
without it. (git-annex copy does)

move/copy: option parsing for --from with --to

Allowing --from and --to as an alternative to --from or --to
is hard to do with optparse-applicative!

The obvious approach of (pfrom <|> pto <|> pfromandto) does not work
when pfromandto uses the same option names as pfrom and pto do.
It compiles but the generated parser does not work for all desired
combinations.

Instead, have to parse optionally from and optionally to. When neither
is provided, the parser succeeds, but it's a result that can't be
handled. So, have to giveup after option parsing. There does not seem to
be a way to make an optparse-applicative Parser give up internally
either.

Also, need seek' because I first tried making fto be a where binding,
but that resulted in a hang when git-annex move was run without --from
or --to. I think because startConcurrency was not expecting the stages
value to contain an exception and so ended up blocking.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

comment

findkeys: New command, very similar to git-annex find but operating on keys

I've long been asked for `git-annex find --all` or something like that,
but pushed back on it because I feel that the command is analagous to
find(1) and so it would be surprising for it to list keys rather than
files. So instead, add a new findkeys subcommand.

Note that the use of withKeyOptions is rather strange because usually
that is used to fall back to --all rather than listing files, but here
it's made to default to --all like behavior and never list files.

A performance thing that could be improved is that withKeyOptions
always reads and caches location logs. But findkeys with no options does
not need them, so it could be made faster. That caching does speed up
options like --in though. This is really just a subset of a more general
performance thing that --all reads location logs sometimes unncessarily.
Anyway, it needs to read the location log in order to checkDead,
and it seems good that findkeys does skip dead keys.

Also, cleaned up comments on git-annex-find man page asking for --all
option.

Sponsored-by: Dartmouth College's DANDI project

fix misleading helper function name

noworktreeitems was false for NoWorkTreeItems which was hard to understand.

Sponsored-by: Dartmouth College's DANDI project

comment

comment

Added a comment: comment 1 response

Added a comment

Added a comment

Added a comment

comment

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

comment

initial report on difficulty moving frozen file

comment

comment

response

comment

close wontfix with submitter agreement

close as dup

comment

comment

close wontfix

close

close

close wontfix

comment

close this old todo

comment

respond and wontfix

comment

comment

Added a comment

added an optional cost= configuration to all special remotes

Note that when this is specified and an older git-annex is used to
enableremote such a special remote, it will simply ignore the cost= field
and use whatever the default cost is.

In passing, fixed adb to support the remote.name.cost and
remote.name.cost-command configs.

Sponsored-by: Dartmouth College's DANDI project

remove a debug print and fix build