comments

2 files changed, 52 insertions, 0 deletions

diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment
new file mode 100644
index 000000000..ba7c8ded8
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""SETURLPRESENT"""
+ date="2016-10-31T18:51:07Z"
+ content="""
+git-annex does not keep track of which urls belong to which remote.
+Urls are, after all, Universal; it shoudn't matter which remote
+set an url.
+
+So, if `SETURLPRESENT` was used, and if git-annex thinks that the web
+special remote is recorded as having the content, it will try to download
+from that url, as well as any other urls that might be set.
+
+But, `SETURLPRESENT` does not make it think that the web special remote
+has the content. So, if the special remote that git-annex does think has to
+content is not enabled, `git annex get` won't try the web special remote.
+
+So, what you can do is run `git annex setpresentkey $key 00000000-0000-0000-0000-000000000001`
+to make it think  the web special remote has the url after `SETURLPRESENT`.
+Then it'll be the same as if `addurl` had been used; it will download from
+the web.
+
+(There's also a way to enable a external special remote in readonly mode.
+In this mode, the special remote program does not have to be in PATH, and
+when git-annex wants to get content from the remote it will download
+content from any urls.)
+
+(The difference with `SETURIPRESENT` is that it's assumed the URI cannot
+be downloaded via HTTP/FTP. So, while `git annex whereis` displays
+URIs, git-annex won't try to download them itself.)
+"""]]
diff --git a/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment
new file mode 100644
index 000000000..ccef300fc
--- /dev/null
+++ b/doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""associated files"""
+ date="2016-10-31T19:12:56Z"
+ content="""
+git-annex keeps track of the AssociatedFile, which (when available) is 
+the worktree file corresponding to the Key that's being operated on.
+
+This information is not exposed in the external special remote interface.
+I'm worried that, if it were, people would try to do stuff that
+just can't work, like
+<http://git-annex.branchable.com/todo/dumb__44___unsafe__44___human-readable_backend/>
+
+Worktree files can be renamed or deleted or copied at any time and can have
+multiple versions, and any special remote that used this information to try
+to create something that resembles the worktree would have massive
+problems.
+
+I am having a hard time thinking of any use that an external special remote
+could make of the information that would not be a mistake.
+"""]]