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

4 files changed, 38 insertions, 0 deletions

diff --git a/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment
new file mode 100644
index 000000000..e32059fb6
--- /dev/null
+++ b/doc/bugs/Empty_folders_don__39__t_get_remove/comment_1_9f41638299c214b2ee13f23ab41349da._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 1"
+ date="2013-12-12T19:16:34Z"
+ content="""
+I can't reproduce this. Tested in direct mode (which I assume you're using, but you didn't say), using both command-line `git annex sync`, and using the assistant. In all cases, when the last file in a directory was removed, the directory was deleted.
+
+Please write back with a version number, and an example showing the problem happening.
+"""]]
diff --git a/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment
new file mode 100644
index 000000000..ac5e77d08
--- /dev/null
+++ b/doc/bugs/git-annex_does_not_install_on_windows_without_admin_rights/comment_3_63e4ff79bc683a70dd9a85c66e26e56a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 3"
+ date="2013-12-12T19:33:50Z"
+ content="""
+I've made the installer now request admin rights if run by a non-admin. Hopefully good enough. However, the NSIS docs say that only works on Vista or higher. The old XP I'm using (that will be completely EOLed soon IIRC) still has the problem.
+"""]]
diff --git a/doc/bugs/when_syncing_a_direct_repository__44___git_annex_delete_non_annexed_new_git_files/comment_4_78ccd70a17d776f14ea9193ab55c6732._comment b/doc/bugs/when_syncing_a_direct_repository__44___git_annex_delete_non_annexed_new_git_files/comment_4_78ccd70a17d776f14ea9193ab55c6732._comment
new file mode 100644
index 000000000..20992d2ab
--- /dev/null
+++ b/doc/bugs/when_syncing_a_direct_repository__44___git_annex_delete_non_annexed_new_git_files/comment_4_78ccd70a17d776f14ea9193ab55c6732._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 4"
+ date="2013-12-12T19:56:50Z"
+ content="""
+I have fixed this bug. I apologise for the trouble.
+
+I did not try to make it clean up, so I recommend doing the checkout as shown above, or doing a `git revert` to get the file added back, if you experienced this bug.
+"""]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment
new file mode 100644
index 000000000..182b5eabb
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_12_b697b2ab10705b090a78e7717ec59b18._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.87"
+ subject="comment 12"
+ date="2013-12-12T19:27:23Z"
+ content="""
+@Peter, in your example, it *is* going to use your gpg key to encrypt files. gpg is being used to generate a 256 bit random value (not a key), which will be used as a random seed for HMAC scrambling of the keys stored in the encrypted special remote.
+
+If that's taking too long to generate for your liking, you can pass --fast, which will make gpg use /dev/urandom to generate it rather than /dev/random.
+"""]]