implement exporttree=yes configuration
* Only export to remotes that were initialized to support it. * Prevent storing key/value on export remotes. * Prevent enabling exporttree=yes and encryption in the same remote. SetupStage Enable was changed to take the old RemoteConfig. This allowed only setting exporttree when initially setting up a remote, and not configuring it later after stuff might already be stored in the remote. Went with =yes rather than =true for consistency with other parts of git-annex. Changed docs accordingly. This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
parent
a4328b49d2
commit
28e2cad849
14 changed files with 69 additions and 29 deletions
|
@ -15,13 +15,13 @@ when they want to export a tree. (It would also be possible to drop all content
|
|||
from an existing special remote and reuse it, but there does not seem much
|
||||
benefit in doing so.)
|
||||
|
||||
Add a new `initremote` configuration `exporttree=true`, that cannot be
|
||||
Add a new `initremote` configuration `exporttree=yes`, that cannot be
|
||||
changed by `enableremote`:
|
||||
|
||||
git annex initremote myexport type=... exporttree=true
|
||||
git annex initremote myexport type=... exporttree=yes
|
||||
|
||||
It does not make sense to encrypt an export, so exporttree=true requires
|
||||
(and can even imply) encryption=false.
|
||||
It does not make sense to encrypt an export, so exporttree=yes requires
|
||||
encryption=none.
|
||||
|
||||
Note that the particular tree to export is not specified yet. This is
|
||||
because the tree that is exported to a special remote may change.
|
||||
|
@ -137,7 +137,7 @@ key/value stores. The content of a file can change, and if multiple
|
|||
repositories can export a special remote, they can be out of sync about
|
||||
what files are exported to it.
|
||||
|
||||
Possible solution: Make exporttree=true cause the special remote to
|
||||
Possible solution: Make exporttree=yes cause the special remote to
|
||||
be untrusted, and rely on annex.verify to catch cases where the content
|
||||
of a file on a special remote has changed. This would work well enough
|
||||
except for when the WORM or URL backend is used. So, prevent the user
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue