29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
`git-annex addurl --fast/--relaxed --verifiable` now uses VURL keys,
|
|
which is an improvement over the old, un-verifiable URL keys. But users
|
|
have to know to use it, and can have URL keys in their repository.
|
|
|
|
Note that old git-annex, when in a repo with VURL keys, is still able to
|
|
operate on them fine, even though it doesn't know what they are.
|
|
Only fsck warns about them. So --verifiable could become the default
|
|
reasonably soon. It's not necessary to wait for everyone to have the new
|
|
version of git-annex.
|
|
|
|
It might be good to nudge users to migrate their existing files to VURL
|
|
eventually. Could be a fsck warning about URL keys, at some point after
|
|
--verifiable becomes the default for addurl. Or could be a warning when
|
|
transferring the content between repositories that it's not possible to
|
|
verify it.
|
|
|
|
Of course if users want to continue to use their existing URL keys and
|
|
not be able to verify content, that's fine. Users can also choose to use
|
|
WORM keys if they really want to.
|
|
|
|
However, I don't think there's enough reason to want to use URL keys to add
|
|
configuration of which kind of keys addurl uses, once VURL is the default.
|
|
--[[Joey]]
|
|
|
|
> One way this might cause trouble is that current `git-annex registerurl`
|
|
> and `unregisterurl` (and `fromkey`) when passed an url rather than a key,
|
|
> generates an URL key. If that is changed to generate a VURL key, then
|
|
> it might break some workflow, particularly one where an url was
|
|
> registered as an URL key and is now being unregistered.
|