mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

couple clarifications

Browse source
This commit is contained in:
Joey Hess 2019-10-07 12:20:49 -04:00
parent 586278cfa8
commit ae86cfb5ef
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 3 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/todo/support_multiple_special_remotes_with_same_uuid/comment_6_8c6c6cbfdc82db708d5c693a18d3872c._comment
View file

@ -15,10 +15,12 @@ So it's fine to break such a loop in an arbitrary way.
There would need to be a way to prevent a remote with sameas= from being There would need to be a way to prevent a remote with sameas= from being
used by a version of git-annex that does not support it. One way would be used by a version of git-annex that does not support it. One way would be
to omit the name= parameter from remote.log, and use some other parameter to omit the name= parameter from remote.log, and use some other parameter
for the name. Then old git-annex could not initremote with the wrong uuid. for the name. Then old git-annex could not enableremote with the wrong uuid.
Using remote.name.annex-uuid-sameas=uuid instead of remote.name.annex-uuid Using remote.name.annex-uuid-sameas=uuid instead of remote.name.annex-uuid
would prevent old git-annex from using initialized sameas remotes. would prevent old git-annex from using initialized sameas remotes.
(Need a better name, since the uuid stored there should be the remote's own
uuid (needed to get its RemoteConfig), not the one that sameas= points to.)
Seems that encryption parameter inheritance would happen the same way as Seems that encryption parameter inheritance would happen the same way as
has been discussed above. When constructing the RemoteConfig, copy over the has been discussed above. When constructing the RemoteConfig, copy over the