mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comments

Browse source
This commit is contained in:
Joey Hess 2016-10-31 15:25:28 -04:00
parent 86b64e6acf
commit 5a1fd1b686
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 52 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_3_f667aa26dadadede318d31176292102d._comment Normal file
View file

@ -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.)
"""]]

21
doc/todo/Allow_for_TRANSFER-SUCCESS_to_report_also_a_URL_where_key_could_now_be_obtained_from/comment_4_16d30e86132d6a3cefaa8e2fecbda7ca._comment Normal file
View file

@ -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.
"""]]