Added a comment

Added a comment

Added a comment

Added a comment

migrate: support adding size back to URL keys

migrate: Support adding size to URL keys that were added with --relaxed, by
running eg: git-annex migrate --backend=URL foo

Since url keys cannot be generated, that used to fail. Make it notice that
the backend is not changed, and just get the size of the content.

Sponsored-by: Brock Spratlen on Patreon

update for distributed migration

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

split out todo for special remotes and close the main todo

Merge branch 'master' into distributedmigration

distributed migration for pull and sync --content

pull, sync: When operating on content, automatically hard link objects
that have been migrated.

Added annex.syncmigrations config that can be set to false to prevent
pull and sync from migrating object content.

I think that true is a good default for this config, because it avoids
users having to re-download migrated content or learning about migration.
But, some users will surely not like it, whether because it does take some
time (especially for the first git-annex branch scan when there is a long
history), or because they want to deal with it manually, or because their
filesystem doesn't support hard links and they don't want it to copy
objects.

Sponsored-by: k0ld on Patreon

migrate --apply

And avoid migrate --update/--aply migrating when the new key was already
present in the repository, and got dropped. Luckily, the location log
allows distinguishing from the new key never having been present!

That is mostly useful for --apply because otherwise dropped files would
keep coming back until the old objects were reaped as unused. But it
seemed to make sense to also do it for --update. for consistency in edge
cases if nothing else. One case where --update can use it is when one
branch got migrated earlier, and we dropped the file, and now another
branch has migrated the same file.

Sponsored-by: Jack Hill on Patreon

skip distributed migration to insecure key when annex.securehashesonly is set

This only avoids extra work and a warning messsage. It seems likely that
in such a situation, the user does not want migrations to insecure
hashes, and so best to ignore them as much as possible. If
the user merges a branch that switches annexed files to an insecure
hash, they will notice that the file contents are unavailable,
and git-annex get will tell them the problem then. So it does not seem
useful to have migrate --update also complain about it.

report on the 'Production' build flag not producing a binary that passes the test suite

fix missing space in warning message

always verify content in distributed migration

doc/todo/distributed_migration.mdwn discusses security of distributed
migration, and this was identified as necessary to do.

display filenames in migrate --update

Have to go to a lot of bother to find them, but I think it's worth it
for usability.

Sponsored-by: Luke T. Shumaker on Patreon

migrate --update fully working

Could use some more testing.

When the old key is not present, Command.ReKey.linkKey' will return
False, so this handles that case ok.

But, I do wonder if distributed migration may need to deal with the old
key getting copied into the repository later. In that situation,
re-running migrate --update won't link it to the new key. It may be that
some users will need that. They can delete .git/annex/migrate.log and
run it again, but that is not a good user interface. Maybe either have
a way to re-run all distributed migrations, or record migrations
in a database and scan the db to find migrations to do in a future run?

Sponsored-by: Kevin Mueller on Patreon

migrate --update gets keys

The git log is outputting the diff, but this only looks at the new
files. When we have a new file, we can get the old filename by just
replacing "new" with "old". And then use branchFileRef to refer to it
allows catting the old key.

While this does have to skip past the old files in the diff, it's still
faster than calling git diff separately.

Sponsored-by: Nicholas Golder-Manning on Patreon

Added a comment

removed

Added a comment

Added a comment

started migrate --update

This is most of the way there, but not quite working.

The layout of migrate.tree/ needs to be changed to follow this approach.
git log will list all the files in tree order, so the new layout needs
to alternate old and new keys. Can that be done? git may not document
tree order, or may not preserve it here.

Alternatively, change to using git log --format=raw and extract
the tree header from that, then use
git diff --raw $tree:migrate.tree/old $tree:migrate.tree/new
That will be a little more expensive, but only when there are lots of
migrations.

Sponsored-by: Joshua Antonishen on Patreon

Added a comment

Added a comment: Similar to initremote type=git

Added a comment: --includesamecontent same as  --not --includesamecontent?

removed

Added a comment

make commitMigration interuption safe

Fixed inversion of control issue, so the tree is recorded
in streamLogFile finalizer.

Sponsored-by: Leon Schuermann on Patreon

comment

log migration trees to git-annex branch

This will allow distributed migration: Start a migration in one clone of
a repo, and then update other clones.

commitMigration is a bit of a bear.. There is some inversion of control
that needs some TMVars. Also streamLogFile's finalizer does not handle
recording the trees, so an interrupt at just the wrong time can cause
migration.log to be emptied but the git-annex branch not updated.

Sponsored-by: Graham Spencer on Patreon

add startAction parameter for KeySha

I have a use planned for this in Command.Migrate.

Sponsored-by: unqueued on Patreon

kinda a bug

remove xmpp from special remotes list

It's documentation for something that was removed, so avoid it getting
copied into eg, nice talks about git-annex. ;-)

remove debug print

further thoughts

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

comment

Add link to English re-recording of Yann's git-annex workshop kickoff talk @Tübix2023

Revert "update"

This reverts commit 6f4e3cc8810f125937a2218578ca83ce7f27b198.

update

prevent relatedTemplate from truncating a filename to end in "."

Avoid a problem with temp file names ending in "." on certian filesystems
that have problems with such filenames.

relatedTemplate is quite an ugly hack really; since it doesn't know the max
filename length of the filesystem it can only assume that the filename is
max allowed length. When given the input "lh.aparc.DKTatlas.annot", it
wants to reserve 20 characters for tempfile so it truncates to "lh.". That
ending period is apparently a problem on some filesystem (FAT eats it, but
does not throw EINVAL; ntfs does not seem bothered by it, I don't know what
FUSE filesystem the bug reporter was really using).

Sponsored-by: Brett Eisenberg on Patreon

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

No change. Just subscribing to comments.

rename forum/name_resolution_of___33__dne__33___fails.mdwn to forum/name_resolution_of_dne.mdwn

rename forum/dne.mdwn to forum/name_resolution_of___33__dne__33___fails.mdwn

Added a comment

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

comment

Added a comment: How about a --offline flag?

sync: Fix locking problems during merge when annex.pidlock is set

Presumably git merge sometimes needs to verifiy if a worktree file is
modified, and so will then run git-annex filter-process which would try to
take the pid lock. And for whatever reason, git-annex sync already had the
pidlock held. I have not replicated that, but it does make enough sense to
deploy the workaround.

Like I said back in commit 7bdb0cdc0d6f35d3835e57c3a34740cc98f89719,

   Arguably, it would be better to have a way to make any process git-annex
   runs have the env var set. But then it would need to take the pid lock
   when running any and all processes, and that would be a problem when
   git-annex runs two processes concurrently. So, I'm left doing it ad-hoc
   in places where git-annex really does run a child process, directly
   or indirectly via a particular git command.

Sponsored-by: KDM on Patreon

comment

comment

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

improve message about 1 copy

"Could only verify the existence of 0 out of 1 necessary copy"
does not sound right, but neither does it with "copies".

Kept the "1" rather than "only" or such since numcopies is mentioned.

Sponsored-by: Brock Spratlen on Patreon

Added a comment

Added a comment

Added a comment

new pidlock bug

rename forum/Can__39__t_access_file_from_secondary_client.mdwn to forum/client_repositories_setup_problem.mdwn

update

comment

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

git-annex branch size when storing migration information

Sponsored-by: Jack Hill on Patreon

Added a comment: Another possibility to make --fast faster?

Added a comment

Added a comment

comment

comment

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

copy/move --from-anywhere --to remote

Implementation was simple because it's equivilant to
--from=foo --to remote for each other remote, followed by
--to remote when there's a local copy.

(Or, in the edge case of --from-anywhere --to=here,
it's the same as --to=here.)

Note that, when the local repo does not have a copy,
fromToPerform gets it from a remote, sends it to the destination,
and drops the local copy. Another call to that for a second remote
will notice that the dest now has a copy, and simply drop from the
second remote, avoiding a second transfer.

Also note that, when numcopies doesn't allow dropping it from
everywhere, it will drop it from the cheapest remotes first
(maybe not ideal) up to more expensive remotes, and finally from the local
repo. So the local repo will generally end up holding a copy. Maybe not
ideal in all cases either, but it seems no worse to do that than to end up
with a copy undropped from a remote.

And I'm not entirely happy with the output, eg:

copy bigfile (from r3...) ok
copy bigfile ok

That makes sense if you think of the second line as being
the same as what is output by `git-annex copy bigfile --to bar`,
but it's less clear in this context. Maybe add "(from here...)"?
Also the --json output doesn't have a machine-readable field for
the "from" uuid, and maybe it should?

Sponsored-by: Dartmouth College's DANDI project

fix --from overriding annex-ignore

Make git-annex get/copy/move --from foo override configuration of
remote.foo.annex-ignore, as documented.

This already worked for remotes supporting hasKeyCheap. For others though,
git-annex copy --from foo would silently not do anything, while
git-annex copy --to foo would use the annex-ignored remote.

Also improved the annex-ignore docs, to reflect that `git-annex get`
without --from will skip using annex-ignored remotes, for example.

Sponsored-by: Dartmouth College's DANDI project

Added a comment

add manual: true to ParallelBuild flag

hackage demands that -j be gated behind a build flag with manual: true
set.

add news item for git-annex 10.20231129

releasing package git-annex version 10.20231129

attribution armoring

Read a fun paper where they got chatgpt to emit large chunks of code
https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html
"ChatGPT memorized significant fractions of its training dataset"

comment

close as fixed

response

comment

Added a comment: corrupted bare repo

comment

dial back addition, but keep it

It's a semi-common point of confusion that numcopies is not something
these commands go out and copy files around specifically to satisfy,
without further configuration in preferred content. So this is a good
addition, but it also seemed too long and too specific to the user's
particular situation.

fix some language

findkeys: Support --largerthan and --smallerthan

Sponsored-by: Brett Eisenberg on Patreon

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