Commit graph

11 commits

Author SHA1 Message Date
Joey Hess
67d91c63f7
update 2021-04-12 14:13:44 -04:00
Joey Hess
1e322c329e
update 2021-04-12 13:00:24 -04:00
Joey Hess
4c35d58bfe
comment and analysis 2021-04-12 12:54:46 -04:00
Joey Hess
4694c2bb87
Merge branch 'master' into requirednumcopies 2021-01-06 14:24:09 -04:00
Joey Hess
cc89699457
mincopies
This is conceptually very simple, just making a 1 that was hard coded be
exposed as a config option. The hard part was plumbing all that, and
dealing with complexities like reading it from git attributes at the
same time that numcopies is read.

Behavior change: When numcopies is set to 0, git-annex used to drop
content without requiring any copies. Now to get that (highly unsafe)
behavior, mincopies also needs to be set to 0. It seemed better to
remove that edge case, than complicate mincopies by ignoring it when
numcopies is 0.

This commit was sponsored by Denis Dzyubenko on Patreon.
2021-01-06 14:15:19 -04:00
Joey Hess
8d8cdbec56
branch 2021-01-05 14:28:54 -04:00
Joey Hess
ee86972f66
thought 2020-11-30 13:27:45 -04:00
Joey Hess
7fd20146e1
all easy cases done
bup can't do it after all, because removeKey deletes the git branch. And
the rest seem too hard to tackle today.
2020-06-26 14:24:48 -04:00
Joey Hess
76721b62dd
does not make sense to lockContent on web
Looked into this, and dropKey from web actually removes the url,
so git-annex won't try to get content from it.

So, if lockContent were implemented for web, and the web was left as the
only thing containing an object, another repo could at the same time
drop from web and remove its url, leaving no way to get the object.

Add to that, of course, the web is typically set untrusted, and so
implementing lockContent would not then be useful.

Similar reasoning applies to the bittorrent special remote, as well
as the fact that it does not even implement checkKey.
2020-06-26 13:58:28 -04:00
Joey Hess
b316a85ede
update 2020-06-26 13:54:23 -04:00
Joey Hess
e15ab727eb
comment and todo 2020-06-11 14:05:01 -04:00