thoughts

doc/todo/support_multiple_special_remotes_with_same_uuid/comment_2_8fd57279ec4d0bae6c32c222c88740d8._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-27T15:53:25Z"
+ content="""
+Yet another problem with the sameas idea is that old git-annex won't know
+what the sameas= value means, and will ignore it. So they'd proceed to use
+the wrong uuid for the special remote. That could result in a big mess.
+
+Also, two remotes using the same underlying data need to be encrypted the
+same way. Including using the same cipher= value, which is not a value that
+the user provides. Basically, all the encryption parameters need to be
+shared between two such remotes. 
+
+Also the chunksize parameter needs to be shared, or at least be
+set on both if not to the same value.
+"""]]

doc/todo/support_multiple_special_remotes_with_same_uuid/comment_3_0c213bd1ee39dbc7236540370b92466e._comment

@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2019-09-27T15:59:28Z"
+ content="""
+Alternate idea:
+
+	git annex initremote foo type=directory directory=/foo encryption=shared
+	git annex initremote --sameas=foo foo-rsync type=rsync rsyncurl=server:/foo
+
+The second command would inherit the encryption etc fields from the foo remote,
+and set up the foo-rsync remote with the same uuid as it.
+And it would add additional fields to the remote.log:
+
+	-uuid name=foo type=directory encryption=shared cipher=...
+	+uuid name=foo type=directory encryption=shared cipher=... alt.foo-rsync.type=rsync alt.foo-rsync.rsyncurl=server:/foo
+
+When enableremote foo-rsync is later run and fails to find a name=foo-rsync,
+it can look for a remote with the "alt.foo-rsync.type" field, and generate a
+RemoteConfig with type=rsync rsyncurl=server:/foo encryption=shared cipher=...
+From there the enableremote would proceed as usual.
+"""]]