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

8 files changed, 135 insertions, 1 deletions

diff --git a/doc/bugs/Install_of_git-annex-3.20121112_fails/comment_7_ae4443b8cd069080d1f77fca16aa8b04._comment b/doc/bugs/Install_of_git-annex-3.20121112_fails/comment_7_ae4443b8cd069080d1f77fca16aa8b04._comment
new file mode 100644
index 000000000..99124ebe5
--- /dev/null
+++ b/doc/bugs/Install_of_git-annex-3.20121112_fails/comment_7_ae4443b8cd069080d1f77fca16aa8b04._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnldTTAP8PAifJUmqhRar6RAWNWlRcencw"
+ nickname="Marco"
+ subject="Works"
+ date="2012-11-14T07:01:34Z"
+ content="""
+Thanks Joey for fixing this. Now I got a working version.
+
+Btw would it make sense to reference a stable Yesod version in the cabal file? I'm new to the haskell universe so I don't know what problems would come up with it.
+"""]]
diff --git a/doc/bugs/map_not_respecting_annex_ssh_options__63__.mdwn b/doc/bugs/map_not_respecting_annex_ssh_options__63__.mdwn
new file mode 100644
index 000000000..0d362db21
--- /dev/null
+++ b/doc/bugs/map_not_respecting_annex_ssh_options__63__.mdwn
@@ -0,0 +1,37 @@
+### What steps will reproduce the problem?
+
+1. Have a remote that uses annex-ssh-options to specify an sshkey which is needed to invoke git-annex-shell on that remote.
+2. Run git-annex map.
+
+### What is the expected output? What do you see instead?
+
+I expect to see a map without any errors complaining of commands not recognized.
+
+Instead I see:
+
+    greg@x200s:~/Pictures/Photos$ git-annex map
+    map /home/greg/Pictures/Photos ok
+    map 60justin (sshing...) 
+    ok
+    map rose (sshing...) 
+    fatal: unrecognized command 'cd '/home/greg/Media/Pictures/Photos/' && git config --null --list'
+    git-annex-shell: git-shell failed
+
+relevant part of .git/config:
+
+    [remote "rose"]
+        url = greg@rose.makesad.us:/home/greg/Media/Pictures/Photos/
+        fetch = +refs/heads/*:refs/remotes/rose/*
+        annex-ssh-options = "-i /home/greg/.ssh/annex.x200s_rsa"
+        annex-trustlevel = trusted
+        annex-uuid = c0e4106e-2631-11e2-9749-1bfa37a61069
+
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 3.20121017
+    local repository version: 3
+    default repository version: 3
+    supported repository versions: 3
+    upgrade supported from repository versions: 0 1 2
+
diff --git a/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn b/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
new file mode 100644
index 000000000..7092a5293
--- /dev/null
+++ b/doc/bugs/unlock_fails_silently_with_directory_symlinks.mdwn
@@ -0,0 +1,34 @@
+What steps will reproduce the problem?
+
++    ```~/``` is tracked by git and git annex
++    ```~/text/books/foo``` is annexed
++    ```~/books``` is a symlink to ```text/books```
++    from ```~/``` execute: ```git annex unlock books/foo```
++    which returns immediately with zero exit code and does not unlock foo.
+
+What is the expected output? What do you see instead?
+
++    I expect ```~/text/books/foo`` to be unlocked
+
++    I think ```git annex unlock``` should resolve the symlinks and realize that this is a tracked file.
+
++    Also, I think ```git annex unlock``` should emit an error message if a file explicitly addressed on the commandline can not be acted upon.
+
+What version of git-annex are you using? On what operating system?
+
++    3.20121112 in debian unstable
+
+Please provide any additional information below.
+
++    I can unlock foo if I provide the full path, eg:
+from ```~/``` execute: ```git annex unlock text/books/foo```
+
++    Interestingly, the following _does_ successfully unlock the file: ```cd ~/books && git annex unlock foo```
+
+     So it seems that symlinks in $PWD are being resolved, but not those in file paths passed as arguments.
+
+Thank you, thank you!
+
+      - Jason
+
+jason@jasonwoof.com
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment
new file mode 100644
index 000000000..8ee00709d
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_3_a20f470c5226ac5693eb15146a02b3f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="comment 3"
+ date="2012-11-14T07:31:11Z"
+ content="""
+how about renaming the stored files, them? if you give me a pointer on how the directory names are generated, i can write a script that does the migration (some hash of the file name?). i suppose that's just a relic from another naming scheme, isn't it?
+"""]]
diff --git a/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment
new file mode 100644
index 000000000..e47a32d3e
--- /dev/null
+++ b/doc/bugs/using_old_remote_format_generates_irritating_output/comment_4_a81f06191bc03a7aad5929af99f0634e._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.252.11.120"
+ subject="comment 4"
+ date="2012-11-14T17:31:38Z"
+ content="""
+The new hash directory tree is generated in a simple to explain way. Take the md5sum of the key and the first 3 characters are the first directory, and the next 3 characters are the second directory.
+
+The old hash directory tree is rather harder to explain. It takes the md5sum of the key, but rather than a string, represents it as 4 32bit words. Only the first word is used. It is converted into a string by the same mechanism that would be used to encode a normal md5sum value into a string, but where that would normally encode the bits using the 16 characters 0-9a-f, this instead uses the 32 characters \"0123456789zqjxkmvwgpfZQJXKMVWGPF\". The first 2 letters of the resulting string are the first directory, and the second 2 are the second directory.
+
+There's probably a 1:1 mapping between this special md5 encoding an a regular md5 encoding. But it's certainly easier just to use the existing Haskell implementation of the hash. The following program, which needs to be built inside a git-annex source tree, reads keys on stdin, and outputs their old hash directory tree values, and their new values on stdout.
+
+<pre>
+import Locations
+import Types.Key
+
+main = interact $ \s -> case file2key s of
+        Nothing -> \"bad key\"
+        Just k -> hashDirMixed k ++ \" \" ++ hashDirLower k ++ \"\n\"
+</pre>
+
+<pre>
+joey@gnu:~/src/git-annex>ghc --make convert.hs
+joey@gnu:~/src/git-annex>echo WORM--foo | ./ convert
+gw/Vx/ 91d/46e/
+</pre>
+"""]]
diff --git a/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment b/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment
new file mode 100644
index 000000000..ec2158c22
--- /dev/null
+++ b/doc/design/assistant/blog/day_130__what_now/comment_1_402f00cc034351d8253a797dd4de55bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm7AuSfii_tCkLyspL6Mr0ATlO6OxLNYOo"
+ nickname="Georg"
+ subject="definitely glacier would be cool"
+ date="2012-11-14T08:51:40Z"
+ content="""
+Because having it available as an archival system to move stuff over that you don't expect to constantly need available. But what would be needed is a way to prevent the assistant to pull all the data from there back on your clients. This probably allready is doable with preferred content, but probably needs an easier way to set up - when I tried the new version it immediately started to pull all the stuff from my server repository that I moved there to get my disk space free. So my scenario would be \"move stuff to archives and when I drop it afterwards, keep it dropped locally if at least one archival server has it\".
+"""]]
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
index 2f7f4bc72..0ec484e72 100644
--- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
 Help me prioritize my work: What special remote would you most like
 to use with the git-annex assistant?
 
-[[!poll open=yes 15 "Amazon S3 (done)" 11 "Amazon Glacier" 8 "Box.com" 61 "My phone (or MP3 player)" 15 "Tahoe-LAFS" 5 "OpenStack SWIFT" 23 "Google Drive"]]
+[[!poll open=yes 15 "Amazon S3 (done)" 12 "Amazon Glacier" 9 "Box.com" 61 "My phone (or MP3 player)" 15 "Tahoe-LAFS" 5 "OpenStack SWIFT" 23 "Google Drive"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they
diff --git a/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment
new file mode 100644
index 000000000..eab2e796b
--- /dev/null
+++ b/doc/forum/XMPP_email_setup_says_wrong_password_but_it__39__s_correct._Can_I_provide_some_kind_of_debug_data__63__/comment_3_6afd424edc4095b8f71b136de2a9e64d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U"
+ nickname="Carlo"
+ subject="XMPP"
+ date="2012-11-13T23:26:50Z"
+ content="""
+Just tried a fresh jabber.org address, same error.
+
+Will see if I can get the changed version built. Or are there nightlies?
+"""]]