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

5 files changed, 116 insertions, 0 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>
+"""]]