comments

doc/todo/support_multiple_special_remotes_with_same_uuid/comment_5_4c6aca9ad876a3963e100f008aea0011._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-10-01T19:52:22Z"
+ content="""
+Further problem with namespaces: If two people init new sameas remotes with
+the same uuid at the same time, on merge one of them will be lost.
+"""]]

doc/todo/support_multiple_special_remotes_with_same_uuid/comment_6_8c6c6cbfdc82db708d5c693a18d3872c._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2019-10-01T19:53:06Z"
+ content="""
+Revisiting the idea of using different uuids with a sameas= parameter:
+
+If one remote is marked dead, it ought to be the one that sameas= points
+to, since that's the uuid in the location log. So that's ok.
+
+As long as enableremote does not allow changing the sameas= paramter,
+sameas loops could only occur maliciously, not in normal operation.
+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
+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
+for the name. Then old git-annex could not initremote with the wrong uuid.
+
+Using remote.name.annex-uuid-sameas=uuid instead of remote.name.annex-uuid
+would prevent old git-annex from using initialized sameas remotes.
+
+Seems that encryption parameter inheritance would happen the same way as
+has been discussed above. When constructing the RemoteConfig, copy over the
+encryption parameters from the parent remote.
+
+All in all, using separate uuids instead of name= seems perhaps better.
+"""]]