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

doc/bugs/Crash_when_adding_jabber_account_/comment_1_2dc61ebcfa8919fb839656999c155c52._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:39:00Z"
+ content="""
+Are you using the 64 bit or the 32 bit build? Did you download the standalone tarball? How are you running git-annex exactly? (Using runshell, or by hand?)
+
+A segfault here seems likely to involve the Haskell GNUTLS binding. At least, the only other time git-annex has segfaulted, which also involved jabber, it was a bug in the GNUTLS binding.
+"""]]

doc/bugs/Internal_server_error_adding_USB_drive_on_OS_X/comment_1_b2ef077d87a9da624f20649c21401b5b._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:07:18Z"
+ content="""
+Spaces in the name is a good guess, but does not seem to cause the problem. I just successfully set up a USB drive that has spaces in the name. (Also, git-annex is carefully coded to avoid such problems..)
+
+It seems that the repository is created, but then running `git config` in it fails for some reason. One thing you could do is look at `~/Documents/annex/.git/annex/daemon.log`. It should have any error message output by the command.
+
+Or, you could try, in a shell:
+
+cd \"/Volumes/G-DRIVE slim/annex\"
+git config annex.uuid 6898F314-7817-4CD5-B1C3-588C55522A3B
+
+And see how that is failing.
+"""]]

doc/bugs/No_progress_bars_with_S3/comment_1_33a601201a9fdd2357f1c03e32fa6b9c._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:31:06Z"
+ content="""
+How large are your files? IIRC the S3 progress bar updated with a rather large granularity.
+"""]]

doc/bugs/fsck_should_double-check_when_a_content-check_fails/comment_1_03af24b70adbcd9f4b94d009f6b71d0a._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:26:59Z"
+ content="""
+Why stop at checking twice? The second check could also fail with a read error, and perhaps the third one would succeed. :P
+
+Seriously, I doubt that this is likely to be a benefit with a modern drive. If the file has a read error once, then error correction has already failed, and it's likely to fail again. Even if it managed to succeed the second time, you have a file that is being read wrong some of the time, which is not a good thing for fsck to leave unnoticed.
+
+Fsck moves bad files to `.git/annex/bad`, so the data in them can be recovered if it comes to that. Hopefully
+though, there's a copy of the file in another repository, so git-annex can just get it from there instead.
+"""]]

doc/forum/Detached_git_work_tree__63__/comment_1_28ac35a325fba250721d9f1b7c994960._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:32:51Z"
+ content="""
+Recent versions of git-annex support these variables. I haven't tested it extensively, but AFAIK it works.
+"""]]

doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.7.238"
+ subject="comment 1"
+ date="2013-01-14T16:22:33Z"
+ content="""
+git-annex does not currently prevent multiple uploads of the same file to a rsync special remote. It is able to guard against this when uploading to a git remote, since then the remote runs git-annex-shell, which can detect when an upload is already running. You might want to convert your rsync remote to a git remote.
+
+I hope that rsyncing the same file twice at the same time is safe, but it's certianly excessively expensive.
+"""]]