initremote: When a uuid= parameter is passed, use the specified UUID for the new special remote, instead of generating a UUID.

This can be useful in some situations, eg when the same data can be
accessed via two different special remote backends.

CHANGELOG

@@ -30,6 +30,10 @@ git-annex (6.20170102) UNRELEASED; urgency=medium
   * Fix build with aws 0.16. Thanks, aristidb.
   * assistant: Make --autostart --foreground wait for the children it
     starts. Before, the --foreground was ignored when autostarting.
+  * initremote: When a uuid= parameter is passed, use the specified
+    UUID for the new special remote, instead of generating a UUID.
+    This can be useful in some situations, eg when the same data can be
+    accessed via two different special remote backends.
 
  -- Joey Hess <id@joeyh.name>  Fri, 06 Jan 2017 15:22:06 -0400
 

Command/InitRemote.hs

@@ -46,8 +46,14 @@ start (name:ws) = ifM (isJust <$> findExisting name)
 
 perform :: RemoteType -> String -> R.RemoteConfig -> CommandPerform
 perform t name c = do
-	(c', u) <- R.setup t R.Init Nothing Nothing c def
+	(c', u) <- R.setup t R.Init cu Nothing c def
 	next $ cleanup u name c'
+  where
+	cu = case M.lookup "uuid" c of
+		Just s
+			| isUUID s -> Just (toUUID s)
+			| otherwise -> giveup "invalid uuid"
+		Nothing -> Nothing
 
 cleanup :: UUID -> String -> R.RemoteConfig -> CommandCleanup
 cleanup u name c = do

doc/git-annex-initremote.mdwn

@@ -33,6 +33,12 @@ is run in a new clone, it will attempt to enable the special remote. Of
 course, this works best when the special remote does not need anything
 special to be done to get it enabled.
 
+Normally, git-annex generates a new UUID for the new special remote.
+If you want to, you can specify a UUID for it to use, by passing a
+uuid=whatever parameter. This can be useful in some situations, eg when the
+same data can be accessed via two different special remote backends.
+But if in doubt, don't do this.
+
 # OPTIONS
 
 * `--fast`

doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-02-07T18:59:41Z"
+ content="""
+I've made `initremote` be able to be provided with a uuid=whatever
+parameter to use whatever UUID you like.
+
+Valid use cases include setting up two special remotes that access the same
+data store through two different interfaces. For example, a rsync special
+remote that is also accessible via a NFS mount as a directory special remote.
+
+It can also be used when two unrelated repositories want to use the same
+data store. Of course, dropping data from the data store then becomes a
+problem, since one of the repositories will know it was dropped, and the
+other one won't. Can get into situations where one of the repositories
+was relying on its remote as the only place a file was stored, and so loses
+the only copy it knows about when the other repository moves the content
+from the remote.
+
+For datalad-archives, I think dropping content from that special remote is
+not supported. Which nearly avoids such problems. If so, it should be fine
+to reuse some UUID for all the datalad-archives special remotes in
+different unrelated datalad repositories.
+"""]]