Merge branch 'master' of ssh://git-annex.branchable.com

6 files changed, 102 insertions, 1 deletions

diff --git a/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment b/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment
new file mode 100644
index 000000000..d86de4e1b
--- /dev/null
+++ b/doc/bugs/Using_a_revoked_GPG_key/comment_9_f50c802d78041fd1522f0e7599ce6a45._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="guilhem"
+ ip="129.16.20.209"
+ subject="comment 9"
+ date="2013-08-22T18:42:28Z"
+ content="""
+Hehe, I ran into the option parser issue when implementing that change
+;-) So I moved to `git annex enableremote ... [keyid+=newkey]
+[keyid-=oldkey]` (where `+` is optional, for consistency) which doesn't
+prevent users from specifying a key by something starting with a sign.
+
+While it's certainly possible to tell git-annex to manage the authorized
+keys itself, users may have other reasons to remove a key so I'm not 
+sure it's a good idea. Also, what if someone forgets to add his/her new 
+key after revocation (it's still possible to decrypt after all)? If 
+another person updates the keyring afterwards, the first user will be
+denied further access, and will have to retrieve and reencrypt the
+\"cipher\" manually, which is not so trivial.
+
+
+I understand that asymmetric encryption needs special care, but Sam's 
+use case could be reproduced with that scheme I believe. For instance a
+user may superseed and revoke his/her old key; then new files would be 
+uploaded with the new one, but as long as the old key is not 
+compromised, I don't see why s/he should reupload everything instead of
+using the old key when pulling from the remote. Of course one may argue
+that the key shouldn't be revoked at the first place, but if it's used
+for other purposes (e.g., it's publicly available on a key server) it's
+good practice to revoke it IMHO.
+
+As for the removal of keys with pure asymmetric encryption, it is just
+required I think: Otherwise revoking a key would prevent any further 
+content to be encrypted. There I can't see any problem with git-annex 
+managing the keyring itself (beside the extra code to write :-P).
+
+All in all if we are to allow deletion/addition of keyIDs (and I think 
+we should!), I think it should be done for both `hybrid` and `pubkey` 
+schemes. Do you really want another syntax? I'd say clarify the manage 
+(plus maybe a warning when running the CLI) is enough, but true it's 
+easy to shoot oneself in the foot there...
+
+"""]]
diff --git a/doc/special_remotes.mdwn b/doc/special_remotes.mdwn
index 978989503..a0102fcaa 100644
--- a/doc/special_remotes.mdwn
+++ b/doc/special_remotes.mdwn
@@ -18,7 +18,15 @@ They cannot be used by other git commands though.
 * [[hook]]
 
 The above special remotes can be used to tie git-annex 
-into many cloud services. Here are specific instructions
+into many cloud services. 
+
+There are many use cases for a special remote. You could use it as a backup. You could use it to archive files offline in a drive with encryption enabled so if the drive is stolen your data is not. You could git annex move --to specialremote large files when your local drive is getting full, and then git annex move the files back when free space is again available. You could have one repository copy files to a special remote, and then git annex get them on another repository, to transfer the files between computers that do not communicate directly. 
+
+The git-annex assistant makes it easy to set up rsync remotes using this last scenario, which is referred to as a transfer repository, and arranges to drop files from the transfer repository once they have been transferred to all known clients.
+
+None of these use cases are particular to particular special remote types. Most special remotes can all be used in these and other ways. It largely doesn't matter for your use what underlying transport the special remote uses.
+
+Here are specific instructions
 for various cloud things:
 
 * [[Amazon_S3|tips/using_Amazon_S3]]
diff --git a/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment b/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment
new file mode 100644
index 000000000..1e6bf8aa4
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_8_d566113318d0aa7500d76ffe1bd46069._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 8"
+ date="2013-08-22T18:02:00Z"
+ content="""
+There are many use cases for a rsync special remote. You could use it as a backup. You could use it to archive files offline in a drive with encryption enabled so if the drive is stolen your data is not. You could `git annex move --to rsyncremote` large files when your local drive is getting full, and then `git annex move` the files back when free space is again available. You could have one repository copy files to a rsync remote, and then `git annex get` them on another repository, to transfer the files between computers that do not communicate directly. The git-annex assistant makes it easy to set up rsync remotes using this last scenario, which is referred to as a transfer repository, and arranges to drop files from the transfer repository once they have been transferred to all known clients.
+
+None of these use cases are particular to rsync remotes. Most special remotes can all be used in these and other ways. It largely doesn't matter for your use what underlying transport the special remote uses.
+"""]]
diff --git a/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment b/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment
new file mode 100644
index 000000000..b7690cf68
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_9_5dcf10a502b2d4feac46b620d43e9d00._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://olivier.berger.myopenid.com/"
+ nickname="obergix"
+ subject="Added use cases to "special remotes""
+ date="2013-08-22T20:23:13Z"
+ content="""
+Thanks @joeyh. I've taken the liberty to add your use case description to [[special remotes]]. Hope this helps.
+"""]]
diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment
new file mode 100644
index 000000000..a25b3c89d
--- /dev/null
+++ b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_2_81f7f893ac36c145b31f02db6a682a17._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="quvi thoughts. excited!"
+ date="2013-08-22T18:22:51Z"
+ content="""
+Anarcat's quvi suggestion is interesting, because it seems to simplify the whole thing down to just `addurl`, which git-annex is already good at.
+
+If quvi manages to find the url that can be used to download the actual video file, without needing to run a special downloader, then all you really need, it seems, is `git annex addurl --relaxed $(quvi youtube-url)` The --relaxed will make git-annex not care if the content or size of the url's content varies in the future. Since --relaxed skips the actual download, you'd want to follow that with `git annex get`, since we don't know how long these urls will last..
+
+I suppose git-annex could, if quvi is available, make any attempt to download a web special remote url that
+matches the `quvi --support` output run the url through quvi to get the real url and download that instead. The  difficulties with this approach:
+
+* would need to read and parse `quvi --support` every time it gets an url from the web special remote? (I don't think I'd want to link with libquvi, although that would be possible, just because this is an edge thing.)
+* what it an url that had been supported stopped being supported -- we'd not want to download the raw url in that case
+* putting the quvi support here doesn't allow relaxed mode to be set when `addurl` adds the url.
+
+Maybe it would be better to keep the support in `addurl`, and record the url generated by quvi. That url would probably be more likely to break in the future, but that kind of breakage is why `git annex untrust web` is wise..
+Keeping the support in `addurl` would also let it use the title that quvi also returns to determine the filename it creates.
+"""]]
diff --git a/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment
new file mode 100644
index 000000000..c4d8cf754
--- /dev/null
+++ b/doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote/comment_3_a7e3cd68c5e5f05139151a58f358df95._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 3"
+ date="2013-08-22T18:44:15Z"
+ content="""
+Since the quvi urls are quite likely to break as the CDNs etc change things around, maybe it would be better to somehow have addurl tag an url as needing to be downloaded with quvi. Then `git annex get` could re-run quvi to get an url to download.
+
+We could expand url syntax for this. `quvi:http://youtube.com/foo`  
+This also allows for future expansion for other similar things. 
+
+I'd be inclined to still make `addurl` automatically try quvi to see if an url is supported, rather than requiring the user fix up the url themselves. But if trying quvi turns out to be too expensive, manually specifying it in the url would also work.
+"""]]