Commit graph

44025 commits

Author SHA1 Message Date
Joey Hess
c18c353a76
Merge branch 'master' of ssh://git-annex.branchable.com 2023-11-26 13:00:35 -04:00
Yann Büchau
0e4fc0f399
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.
2023-11-24 12:08:09 +01:00
branch
8525019a06 2023-11-22 22:02:40 +00:00
Joey Hess
c9b766b914
comment 2023-11-21 16:45:03 -04:00
nobodyinperson
574196b887 Added a comment 2023-11-21 20:20:14 +00:00
Joey Hess
c3dd670609
comment 2023-11-21 16:16:27 -04:00
Joey Hess
e08f170b0e
followup and wontfix this 2023-11-21 16:11:10 -04:00
Joey Hess
96c269e087
comment 2023-11-21 16:02:21 -04:00
Joey Hess
a16ad2096b
close 2023-11-21 15:59:18 -04:00
Joey Hess
7ff40bc5be
move a comment that is a bug report 2023-11-21 15:57:10 -04:00
Joey Hess
9e6cee2aa3
Merge branch 'master' of ssh://git-annex.branchable.com 2023-11-21 12:05:47 -04:00
Joey Hess
f1c2e18b8d
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
2023-11-21 11:34:21 -04:00
beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec
30bc55e55e Added a comment 2023-11-21 09:25:33 +00:00
Joey Hess
e901d31feb
exhaustiveness check fix 2023-11-20 21:34:29 -04:00
Joey Hess
06fa528408
golfing 2023-11-20 21:33:09 -04:00
Joey Hess
63c79dceef
avoid displicate of year range 2023-11-20 21:29:19 -04:00
Joey Hess
dab9687184
improve attribution armoring 2023-11-20 21:20:37 -04:00
Joey Hess
d5d570a96c
avoid replacing otherwise
While authorJoeyHess is True same as otherwise, ghc's exhastiveness
checker turns out to special case otherwise. So this avoids warnings.
2023-11-20 20:25:51 -04:00
Joey Hess
00933f69df
fix build 2023-11-20 20:08:35 -04:00
Joey Hess
70f7982ef8
Merge branch 'master' of ssh://git-annex.branchable.com 2023-11-20 12:29:44 -04:00
Joey Hess
cda3e85164
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
9562da790f. 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
2023-11-20 12:29:12 -04:00
NewUser
fc10ac3be2 Added a comment 2023-11-20 13:17:03 +00:00
nobodyinperson
3de99793d3 Added a comment: forgot to add the new ignored link + shortcoming of 'ln' command 2023-11-20 10:25:52 +00:00
NewUser
3a4883cabb Added a comment: Is annex.tune.objecthashlower=true recommended for interop with windows? 2023-11-20 04:24:35 +00:00
NewUser
544767a5a4 Added a comment: git annex uninit fails when I symlink your symlink 2023-11-20 04:22:02 +00:00
NewUser
f8f1670005 2023-11-20 02:09:42 +00:00
NewUser
289266618a Added a comment: Thanks Yann! 2023-11-19 18:20:03 +00:00
nobodyinperson
37e5866cd1 Added a comment 2023-11-19 16:27:35 +00:00
nobodyinperson
f4bde53022 Make it more clear that git annex webapp will add files and sync via the assistant. 2023-11-19 16:26:44 +00:00
nobodyinperson
3cd54476b5 Added a comment 2023-11-19 16:16:15 +00:00
NewUser
d5664ac5e2 Added a comment: launching git annex webapp starts adding to the annex which is surprising 2023-11-18 20:08:18 +00:00
NewUser
c727550f68 Added a comment: launching git annex webapp starts adding to the annex which is surprising 2023-11-18 20:03:06 +00:00
yarikoptic
dbf1f5d6d6 Added a comment 2023-11-18 01:35:35 +00:00
Joey Hess
6e3bcbf4dd
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 d006586cd0
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
2023-11-17 17:37:58 -04:00
Joey Hess
96c0e720c5
small refactoring
Sponsored-by: Dartmouth College's DANDI project
2023-11-17 17:23:24 -04:00
Joey Hess
9f6609d2b1
fixed 2023-11-17 16:46:43 -04:00
Joey Hess
7a8393ce7d
Fix bug in git-annex copy --from --to
Caused it to skip files that were locally present.

Sponsored-by: Dartmouth College's DANDI project
2023-11-17 16:30:20 -04:00
Joey Hess
f2f6dbe46b
comment 2023-11-17 16:17:44 -04:00
nobodyinperson
c2620ac4ca 2023-11-17 11:47:53 +00:00
imlew
0120334a51 Added a comment: thank you 2023-11-17 11:43:39 +00:00
nobodyinperson
929db5c5cf Added a comment 2023-11-17 09:49:02 +00:00
imlew
55a7fce119 Added a comment 2023-11-17 09:41:19 +00:00
nobodyinperson
adfe5a4a4c Added a comment 2023-11-17 08:45:56 +00:00
imlew
144500f19d Added a comment: one more question 2023-11-17 08:23:32 +00:00
imlew
2dedf68e53 Added a comment: not about backends after all 2023-11-17 08:09:23 +00:00
yarikoptic
27e705ea72 remove content of now independent issue https://git-annex.branchable.com/bugs/copy_--from_--to_does_not_copy_if_present_locally/ 2023-11-17 02:23:17 +00:00
yarikoptic
0bde6e8cf4 initial dedicated issue on copy --from --to not copying if present locally 2023-11-17 02:07:35 +00:00
yarikoptic
7205876d23 initial report on --fast of being no effect for copy --from --to 2023-11-16 17:54:49 +00:00
nobodyinperson
0018e5769e Added a comment 2023-11-16 16:34:13 +00:00
nobodyinperson
0a43bcb71b Added a comment 2023-11-16 15:55:49 +00:00