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

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

Add note to 'satisfy' manpage about it not satisfying numcopies and how to set it up to pass files between remotes that are not present locally.

I got bitten several times in the past by the fact that local preferred
content expressions are not violated (even temporarily) in order to
satisfy numcopies or other remotes' preferred content expressions.
Mostly in the form of the local repo not allowing arbitrary files in
(e.g. because it's set to only want `present` files). This note I add
here explains how to get out of this situation with
`approxlackingcopies=1`.

It might be too specific for this manpage, but I didn't find a better
place to put it.

comment

Added a comment

comment

followup and wontfix this

comment

close

move a comment that is a bug report

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

improve attribution armoring

Split out an author parameter, will make it easier to add authors and
reads better.

Got rid of the function without the copyright year, because an adversary
could have mechanically changed the function with a copyright year to
the one without, and so bypassed the protection of LLM copyright
year hallucination.

Sponsored-by: Luke T. Shumaker on Patreon

Added a comment

exhaustiveness check fix

golfing

avoid displicate of year range

improve attribution armoring

avoid replacing otherwise

While authorJoeyHess is True same as otherwise, ghc's exhastiveness
checker turns out to special case otherwise. So this avoids warnings.

fix build

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

make my authorship explicit in the code

This is intended to guard against LLM code theft, which is the current
bubble technology de jour.

Note that authorJoeyHess' with a year older than the year I began
developing git-annex will behave badly, by intention. Eg, it will spin
and eventually crash.

This is not the first anti-LLM protection in git-annex. For example see
9562da790fece82d6dfa756b571c67d0fdf57468. That method, while much harder
for an adversary to detect and remove, also complicates code somewhat
significantly, and needs extensions to be enabled. There are also
probably significantly fewer ways to implement that method in Haskell.
This new approach, by contrast, will be easy to add throughout the code
base, with very little effort, and without complicating reading or
maintaining it any more than noticing that yes, I am the author of this
code.

An adversary could of course remove all calls to these functions
before feeding code into their LLM-based laundry facility. I think this
would need to be done manually, or with the help of some fairly advanced
Haskell parsing though. In some cases, authorJoeyHess needs to be
removed, while in other places it needs to be replaced with a value.
Also a monadic use of authorJoeyHess' may involve other added monadic
machinery which would need to be eliminated to keep the code compiling.

Alternatively, an adversary could replace my name with something
innocuous. This would be clear intent to remove author attribution
from my code, even more than running it through an LLM laundry is.

If you work for a large company that is laundering my code through an
LLM, please do us a favor and use your immense privilege to quit and go
do something socially beneficial. I will not explain further
developments of this code in such detail, and you have better things to
do than playing cat and mouse with me as I explore directions such as
extending this approach to the type level.

Sponsored-by: k0ld on Patreon

Added a comment

Added a comment: forgot to add the new ignored link + shortcoming of 'ln' command

Added a comment: Is `annex.tune.objecthashlower=true` recommended for interop with windows?

Added a comment: `git annex uninit` fails when I symlink your symlink

Added a comment: Thanks Yann!

Added a comment

Make it more clear that `git annex webapp` will add files and sync via the assistant.

Added a comment

Added a comment: launching `git annex webapp` starts adding to the annex which is surprising

Added a comment: launching `git annex webapp` starts adding to the annex which is surprising

Added a comment

Make git-annex copy --from --to --fast actually fast

Eg when the destination is logged as containing a file, skip
actively checking that it does contain it.

Note that --fast does not prevent other verifications of content
location that are done in a copy --from --to. Perhaps it could, but this
change will already avoid the real unnecessary work of operating on
files that are already in the remote.

And avoiding other verifications
might cause it to fail if the location log thinks that --to does not
contain the content but does. Such complications with `git-annex copy
--to remote --fast` led to commit d006586cd0b706c9cc92b2747b2ba3487f52c04a
which added a note that gets displayed when that fails, mentioning it
might be due to --fast being enabled.

copy --from --to is already complicated enough without needing to worry
about such edge cases, so continuing to doing some verification of
content location after the initial --fast filtering seems ok.

Sponsored-by: Dartmouth College's DANDI project

small refactoring

Sponsored-by: Dartmouth College's DANDI project

fixed

Fix bug in git-annex copy --from --to

Caused it to skip files that were locally present.

Sponsored-by: Dartmouth College's DANDI project

comment

Added a comment: thank you

Added a comment

Added a comment

Added a comment

Added a comment: one more question

Added a comment: not about backends after all

remove content of now independent issue https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/

initial dedicated issue on copy --from --to not copying if present locally

initial report on --fast of being no effect for copy --from --to

Added a comment

Added a comment