export tree: avoid confusing output about renaming files

When a file in the export is renamed, and the remote's renameExport
returned Nothing, renaming to the temp file would first say it was
renaming, and appear to succeed, but actually what it did was delete the
file. Then renaming from the temp file would not do anything, since the
temp file is not present on the remote. This appeared as if a file got
renamed to a temp file and left there.

Note that exporttree=yes importree=yes remotes have their usual
renameExport replaced with one that returns Nothing. (For reasons
explained in Remote.Helper.ExportImport.) So this happened
even with remotes that support renameExport.

Fix by letting renameExport = Nothing when it's not supported at all.
This avoids displaying the rename.

Sponsored-by: Graham Spencer on Patreon

fix comment

update

fix comment

update

fix indent for readability

attribution armoring

add reregisterurl command

What this can currently be used for is only to change an url from being
used by a special remote to being used by the web remote.

This could have been a --move-from option to registerurl. But, that would
have complicated its option and --batch processing, and also would have
complicated unregisterurl, which is implemented on top of
Command.Registerurl. So, a separate command was actually less complicated
to implement.

The generic description of the command is because I want to make this
command a catch-all for other url updating kind of things, if there are
ever any more. Also because it was hard to come up with a good name for the
specific action. I considered `git-annex moveurl`, but that seems to
indicate data is perhaps actually being moved, and seems to sit at the same
level as addurl and rmurl, and this command is at the plumbing
level of registerurl and unregisterurl.

Sponsored-by: Dartmouth College's DANDI project

small problem

comment

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

add todo for tracking free space in repos via git-annex branch

For balanced preferred content perhaps, or just for git-annex info
display.

Sponsored-by: unqueued on Patreon

update

Added a comment

response

comment

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

thoughts

Added a comment

clarification

implement VURL to URL migration

Just for completeness, someone might want to downgrade I guess?

add potential list

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

implement URL to VURL migration

This needs the content to be present in order to hash it. But it's not
possible for a module used by Backend.URL to call inAnnex because that
would entail a dependency loop. So instead, rely on the fact that
Command.Migrate calls inAnnex before performing a migration.

But, Command.ExamineKey calls fastMigrate and the key may or may not
exist, and it's not wanting to actually perform a migration in any case.
To handle that, had to add an additional value to fastMigrate to
indicate whether the content is inAnnex.

Factored generateEquivilantKey out of Remote.Web.

Note that migrateFromURLToVURL hardcodes use of the SHA256E backend.
It would have been difficult not to, given all the dependency loop
issues. But --backend and annex.backend are used to tell git-annex
migrate to use VURL in any case, so there's no config knob that
the user could expect to configure that.

Sponsored-by: Brock Spratlen on Patreon

fix typo in example

todo

comment

handle multiple VURL checksums in one pass

git-annex fsck and some other commands that verify the content of a key
were using the non-incremental verification interface. But for VURL
urls, that interface is innefficient because when there are multiple
equivilant keys, it has to separately read and checksum for each key in
turn until one matches. It's more efficient for those to use the
incremental interface, since the file can be read a single time.

There's no real downside to using the incremental interface when available.

Note that more speedup could be had for VURL, if it was able to
calculate the checksum a single time and then compare with the
equivilant keys checksums. When the equivilant keys use the same type of
checksum.

Sponsored-by: k0ld on Patreon

nub the equivilant key list

If somehow the same key gets listed in the log twice, avoid doing double
checksumming.

fix comment typo

update

avoid double checksum when downloading VURL from web for 1st time

Sponsored-by: Jack Hill on Patreon

incremental verification for VURL

Sponsored-by: Brett Eisenberg on Patreon

has potential in DANDI project

add future todo

verifyKeyContent for VURL

VURL is now fully working, though needs more testing.

Still need to implement verifyKeyContentIncrementally but it works
without it.

Sponsored-by: Luke T. Shumaker on Patreon

implement isCryptographicallySecureKey for VURL

Considerable difficulty to work around an import cycle. Had to move the
list of backends (except for VURL) to Backend.Variety to VURL could use
it.

Sponsored-by: Kevin Mueller on Patreon

lift isCryptographicallySecure to Annex

Needed for VURL backend.

Sponsored-by: Nicholas Golder-Manning on Patreon

add equivilant key log for VURL keys

When downloading a VURL from the web, make sure that the equivilant key
log is populated.

Unfortunately, this does not hash the content while it's being
downloaded from the web. There is not an interface in Backend currently
for incrementally hash generation, only for incremental verification of an
existing hash. So this might add a noticiable delay, and it has to show
a "(checksum...") message. This could stand to be improved.

But, that separate hashing step only has to happen on the first download
of new content from the web. Once the hash is known, the VURL key can have
its hash verified incrementally while downloading except when the
content in the web has changed. (Doesn't happen yet because
verifyKeyContentIncrementally is not implemented yet for VURL keys.)

Note that the equivilant key log file is formatted as a presence log.
This adds a tiny bit of overhead (eg "1 ") per line over just listing the
urls. The reason I chose to use that format is it seems possible that
there will need to be a way to remove an equivilant key at some point in
the future. I don't know why that would be necessary, but it seemed wise
to allow for the possibility.

Downloads of VURL keys from other special remotes that claim urls,
like bittorrent for example, does not popilate the equivilant key log.
So for now, no checksum verification will be done for those.

Sponsored-by: Nicholas Golder-Manning on Patreon

support VURL backend

Not yet implemented is recording hashes on download from web and
verifying hashes.

addurl --verifiable option added with -V short option because I
expect a lot of people will want to use this.

It seems likely that --verifiable will become the default eventually,
and possibly rather soon. While old git-annex versions don't support
VURL, that doesn't prevent using them with keys that use VURL. Of
course, they won't verify the content on transfer, and fsck will warn
that it doesn't know about VURL. So there's not much problem with
starting to use VURL even when interoperating with old versions.

Sponsored-by: Joshua Antonishen on Patreon

comment

fix link

Added dependency on unbounded-delays

And stop vendoring part of it.

This is a free dependency because tasty depends on it.

Sponsored-by: Leon Schuermann on Patreon

add news item for git-annex 10.20240227

releasing package git-annex version 10.20240227

comment and todo

comment

Added a comment: ignore, upgrading to v10.20231227 solved this issue

Added a comment: this also fails with encryption=none

comment

close

comment

move misplaced bug or todo to a better place

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

Add logo version with '> git annex' text below

Added a comment: Datalad cannot detect submodule path changed on disk

git-annex.branchable.com/submodules/#comment-2f017a0f1a13329f4f738568b3eb82ae

Added a comment

Added a comment: Using fsck is an option?

Added a comment: Colocating git-annex and git-lfs

Added a comment: Multi-line string in WHEREIS-SUCCESS?

Pass --no-warnings to yt-dlp

Notice a warning with -J2 causing git-annex progress output to get slightly
messed up.

Error output would also probably do that, so perhaps it should capture
stderr and only display it when yt-dlp exited nonzero?

This option might also make sense for youtube-dl, I don't have an
installation handy anymore to check.

expand on what i feel a tweak could help

Add annextimelog project

add openneuro project

comment

Added a comment

removed

Fix typo

Added a comment: a script to hide history

Explicitly specify 1.0 Debian source format

This is what has always been used, avoids a build warning.

Using 3.0 (native) would be better, but risks breaking builds that
modify this debian directory. Eg, if someone adds -1 to the version
number, they would also have to change away from native source format.

update thanks and separate out 2023 name list

Suggest cooperating with hellotux.com for git-annex-branded shirts

pre-commit: Avoid committing the git-annex branch

Except when a commit is made in a view, which changes metadata.

Make the assistant commit the git-annex branch after git commit of working
tree changes.

This allows using the annex.commitmessage-command in the assistant to
generate a commit message for the git-annex branch that relies on state
gathered during the commit of the working tree. Eg, it might reuse the
commit message.

Note that, when not using the assistant, a git-annex add still commits
the git-annex branch, so such a annex.commitmessage-command set up would
not work then. But if someone is using the assistant and wants
programmatic control over commit messages, this is useful. Someone not
using the assistant can get the same result by using annex.alwayscommit=false
during the git-annex add, and git-annex merge after they git commit.

pre-commit was never really intended to commit the git-annex branch
(except after recording changed metadata), but the assistant did sort of
rely on it. It does later commit the git-annex branch before pushing to
remotes, but I didn't want to risk building up lots of uncommitted changes
to it if that didn't happen frequently.

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

added annex.commitmessage-command config

Sponsored-by: the NIH-funded NICEMAN (ReproNim TR&D3) project

comment

Added a comment

removed

Added a comment

top

improved approach

remove comment that doesn't actually work

update

comment

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

design document for verified relaxed urls

Sponsored-by: Graham Spencer on Patreon

close as distributed migration meets this use case

Added a comment: Update: workaround with branches

Added a comment: This behavior should be the default one

Added a comment

comment