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.

2 files changed, 31 insertions, 0 deletions

diff --git a/doc/git-annex-initremote.mdwn b/doc/git-annex-initremote.mdwn
index 1b46ff536..d47c66506 100644
--- a/doc/git-annex-initremote.mdwn
+++ b/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`
diff --git a/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment b/doc/todo/be_able_to_refer_to_remotes_by_uuid/comment_2_8ace9ec8cb5264fd424b3bc550d96ba5._comment
new file mode 100644
index 000000000..fc22f0c90
--- /dev/null
+++ b/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.
+"""]]