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

7 files changed, 118 insertions, 3 deletions

diff --git a/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
new file mode 100644
index 000000000..55e8c1244
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="WHEREIS -- is it better to just report failure to avoid duplicates?"
+ date="2015-08-26T14:22:49Z"
+ content="""
+I wonder how should I utilize this new API (WHEREIS) in my case:  it seems just to lead to duplication of whereis information in my case of a special remote to support extracting of content from archives. If I make it to reply with the same url (which is not \"public\" per se, i.e. can't be used by annex directly) I just get it duplicated:
+
+    $> git annex whereis simple.txt
+    whereis simple.txt (1 copy) 
+      	82025765-5cac-4571-91ed-637620ec6fc7 -- [annexed-archives]
+    
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+    ok
+
+if I \"explain\" it a bit, also somewhat duplicate:
+
+    annexed-archives: file a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20 within archive SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz
+    annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+
+But if I just reply with \"WHEREIS-FAILURE\" it becomes more sensible (no duplicates), but I feel that then better documentation for this feature get adjusted to describe
+that it is only to complement information already known to annex, and not really to \"provide any information about ways to access the content of a key stored in it\".  Or have I missed the point? ;)
+"""]]
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
new file mode 100644
index 000000000..fc94528fa
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jean.jordaan@4bb3bd508a9eb0a4bab5d1b587dadd2b6c4a7edc"
+ nickname="jean.jordaan"
+ subject="recoll: there's a Unity Lens for it"
+ date="2015-08-26T13:04:12Z"
+ content="""
+I see there is an Ubuntu Unity search lens for recoll: http://www.webupd8.org/2012/03/recoll-lens-full-text-search-unity-lens.html
+It should be possible to integrate git-annex metadata with that ..
+"""]]
diff --git a/doc/forum/removing_remote.log_information_completely.mdwn b/doc/forum/removing_remote.log_information_completely.mdwn
new file mode 100644
index 000000000..0a0e91cd4
--- /dev/null
+++ b/doc/forum/removing_remote.log_information_completely.mdwn
@@ -0,0 +1,9 @@
+in [[forum/remote-specific_meta-data/]], we have learned how to insert our own remote-specific metadata, in remote.log. now, we need a way to remove that data. for some reason, injecting commits in the `git-annex` branch doesn't quite work, because other assistants will overwrite that merge thanks to the [[git-union-merge]] driver.
+
+so far, i have found that it *can* be possible to work around this problem by repeatedly doing commits on the git-annex branch and running `git-annex sync` by hand after. it stumbles and flips around for a while, but eventually does it. it does create nice sparkles in gitk: 
+
+![a tangled mess in gitk](http://i.imgur.com/PD4ne50.png)]
+
+What is the proper way of removing entries from `remote.log`? How about propagating changes to the `synced/git-annex` branch? I can generate commits on `git-annex` using the git-annex index, and on the `git-annex` branch. But how should those changes be propagated to other branches?
+
+Thanks! --[[anarcat]]
diff --git a/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
new file mode 100644
index 000000000..f033bab9a
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="git-annex,branchable.com@1fa4b21c7ece2d61d4730de8e83329049126cedc"
+ nickname="git-annex,branchable.com"
+ subject="Glacier-cli works, thanks, some encode / decode error now..."
+ date="2015-08-26T08:30:53Z"
+ content="""
+Hi Joey,
+
+Thanks for the hand, it started uploading once I had manually created the vault but then borked with:
+
+    fozz@cobol:~/Store/family_pictures $ git annex --verbose copy 201/2011/05/07/P1010004.RW2 --to familypictures-glacier
+    copy 201/2011/05/07/P1010004.RW2 (gpg) (checking familypictures-glacier...) (to familypictures-glacier...) 
+    81%           4.0MB/s 0sTraceback (most recent call last):
+      File \"/home/fozz/.vendor/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/fozz/.vendor/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/fozz/.vendor/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
+        self._send_part()
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
+        self.send_fn(part)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
+        self.uploader.upload_part(self.next_part_index, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
+        content_range, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+        response_headers=response_headers)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
+        data=data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
+        retry_handler=retry_handler)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
+        request.body, request.headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:17: hPutBuf: resource vanished (Broken pipe)
+    failed                  
+    git-annex: copy: 1 failed
+
+"""]]
diff --git a/doc/todo/autoenable__61__true_for_special_remotes.mdwn b/doc/todo/autoenable__61__true_for_special_remotes.mdwn
new file mode 100644
index 000000000..8b0f01962
--- /dev/null
+++ b/doc/todo/autoenable__61__true_for_special_remotes.mdwn
@@ -0,0 +1,3 @@
+Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459
+
+joey:  I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes.
diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment
new file mode 100644
index 000000000..b04a8c245
--- /dev/null
+++ b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2015-08-25T18:25:44Z"
+ content="""
+There are going to be many configurations where auto-enable of a special remote fails. Ie, when creds are needed. While some of these could be detected and skipped, I sort of like the simplicity of having it try to enable everything.
+
+Maybe a command is also needed to autoenable remotes after the first git-annex init? Since it's actually ok to re-run git-annex init in an initalized repo, I suppose it could just be run again.
+"""]]
diff --git a/doc/trust.mdwn b/doc/trust.mdwn
index a33c6dd42..bfb36b5b9 100644
--- a/doc/trust.mdwn
+++ b/doc/trust.mdwn
@@ -20,7 +20,7 @@ There is still some trust involved here. A semitrusted repository is
 depended on to retain a copy of the file content; possibly the only
 [[copy|copies]].
 
-(Being semitrusted is the default. The `git annex semitrust` command
+(Being semitrusted is the default. The [[git-annex-semitrust]] command
 restores a repository to this default, when it has been overridden.
 The `--semitrust` option can temporarily restore a repository to this
 default.)
@@ -34,7 +34,7 @@ This is a good choice for eg, portable drives that could get lost. Or,
 if a disk is known to be dying, you can set it to untrusted and let
 `git annex fsck` warn about data that needs to be copied off it.
 
-To configure a repository as untrusted, use the `git annex untrust`
+To configure a repository as untrusted, use the [[git-annex-untrust]]
 command.
 
 ## trusted
@@ -49,7 +49,7 @@ access a remote you trust. Or to use `--trust` to specify a repository to
 trust temporarily.
 
 To configure a repository as fully and permanently trusted,
-use the `git annex trust` command.
+use the [[git-annex-trust]] command.
 
 ## dead
 
@@ -57,3 +57,6 @@ This is used to indicate that you have no trust that the repository
 exists at all. It's appropriate to use when a drive has been lost,
 or a directory irretrievably deleted. It will make git-annex avoid
 even showing the repository as a place where data might still reside.
+
+To configure a repository as dead and lost, use the [[git-annex-dead]]
+command.