Recent changes to this wiki:

Added a comment
diff --git a/doc/bugs/ssh_over_IPv6/comment_2_cfa63d226ae411551a728af5ab043491._comment b/doc/bugs/ssh_over_IPv6/comment_2_cfa63d226ae411551a728af5ab043491._comment
new file mode 100644
index 0000000..032e100
--- /dev/null
+++ b/doc/bugs/ssh_over_IPv6/comment_2_cfa63d226ae411551a728af5ab043491._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 2"
+ date="2014-09-01T11:01:30Z"
+ content="""
+thank you. I workaround this by using the DNS hostname instead the IPv6 address directly. But this is not a nice solution, like any workaround. But now i have problems with `git annex get` over IPv6-only:
+
+```
+get ***.mp3 (not available) 
+  Try making some of these repositories available:
+  	5636aefa-c509-4ea0-bebe-f5b96d8eb15a -- hserver
+failed
+<snip>
+```
+
+but i can ping it:
+```
+thomas@alus:~/Musik$ ping6 hserver.h.b128.net
+PING hserver.h.b128.net(fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e) 56 data bytes
+64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=1 ttl=42 time=453 ms
+64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=2 ttl=42 time=441 ms
+64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=3 ttl=42 time=425 ms
+64 bytes from fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e: icmp_seq=5 ttl=42 time=413 ms
+```
+(the high pings are caused by a download from an other source. Also i have no problems with rsync over IPv6)
+
+PS: the markdown for code blocks is not working too :)
+"""]]

Added a comment
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment
new file mode 100644
index 0000000..5de6726
--- /dev/null
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_3_2acff7b667e8618251075031cbef6b9a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="131.252.200.111"
+ subject="comment 3"
+ date="2014-08-31T22:29:44Z"
+ content="""
+Occurs to me that your repo may not have a pre-commit hook; if not then `git commit -a` would not behave as I described..
+"""]]

add news item for git-annex 5.20140831
diff --git a/doc/news/version_5.20140613.mdwn b/doc/news/version_5.20140613.mdwn
deleted file mode 100644
index d441372..0000000
--- a/doc/news/version_5.20140613.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-git-annex 5.20140613 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Ignore setsid failures.
-   * Avoid leaving behind .tmp files when failing in some cases, including
-     importing files to a disk that is full.
-   * Avoid bad commits after interrupted direct mode sync (or merge).
-   * Fix build with wai 0.3.0.
-   * Deal with FAT's low resolution timestamps, which in combination with
-     Linux's caching of higher res timestamps while a FAT is mounted, caused
-     direct mode repositories on FAT to seem to have modified files after
-     they were unmounted and remounted.
-   * Windows: Fix opening webapp when repository is in a directory with
-     spaces in the path.
-   * Detect when Windows has lost its mind in a timezone change, and
-     automatically apply a delta to the timestamps it returns, to get back to
-     sane values."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140831.mdwn b/doc/news/version_5.20140831.mdwn
new file mode 100644
index 0000000..713adb9
--- /dev/null
+++ b/doc/news/version_5.20140831.mdwn
@@ -0,0 +1,13 @@
+git-annex 5.20140831 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Make --help work when not in a git repository. Closes: #[758592](http://bugs.debian.org/758592)
+   * Ensure that all lock fds are close-on-exec, fixing various problems with
+     them being inherited by child processes such as git commands.
+   * When accessing a local remote, shut down git-cat-file processes
+     afterwards, to ensure that remotes on removable media can be unmounted.
+     Closes: #[758630](http://bugs.debian.org/758630)
+   * Fix handing of autocorrection when running outside a git repository.
+   * Fix stub git-annex test support when built without tasty.
+   * Do not preserve permissions and acls when copying files from
+     one local git repository to another. Timestamps are still preserved
+     as long as cp --preserve=timestamps is supported. Closes: #[729757](http://bugs.debian.org/729757)"""]]
\ No newline at end of file

diff --git a/doc/bugs/vicfg_and_description_often_not_propagated.mdwn b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
index dcee90b..d42ba43 100644
--- a/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
+++ b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
@@ -9,6 +9,7 @@ Well that is very hard. I have 8 repos and it happens randomly to some of them.
 ### What version of git-annex are you using? On what operating system?
 
 Linux: git-annex version: 5.20140412ubuntu1
+
 Mac OS: git-annex version: 5.20140717
 
 ### Please provide any additional information below.

diff --git a/doc/bugs/vicfg_and_description_often_not_propagated.mdwn b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
new file mode 100644
index 0000000..dcee90b
--- /dev/null
+++ b/doc/bugs/vicfg_and_description_often_not_propagated.mdwn
@@ -0,0 +1,151 @@
+### Please describe the problem.
+
+I can change the settings in one repo and sync it everywhere. Just to be surprised that one repo starts syncing to the transfer, every time it turns out that this repo lost its vicfg settings. Especially the Repository preferred contents are all back on standard. It was even once that it had the current settings and after the change and sync it goes back to some older state instead of the new one.
+
+### What steps will reproduce the problem?
+
+Well that is very hard. I have 8 repos and it happens randomly to some of them. I recreated all of them recently because I thought they are corrupt, that didn't help, just took me one week of time. It is also very hard to find a way to reproduce this because every vicfg causes a merge which takes minutes to hours.
+
+### What version of git-annex are you using? On what operating system?
+
+Linux: git-annex version: 5.20140412ubuntu1
+Mac OS: git-annex version: 5.20140717
+
+### Please provide any additional information below.
+
+Layout:
+
+transfer on rsync.net, conntented to that:
+
+ - Two OS X Clients
+
+ - Two Linux Archives
+
+My settings:
+
+
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+# git-annex configuration
+# 
+# Changes saved to this file will be recorded in the git-annex branch.
+# 
+# Lines in this file have the format:
+#   setting field = value
+
+# Repository trust configuration
+# (Valid trust levels: trusted semitrusted untrusted dead)
+# (for Music bei Pirmin)
+trust 0734498b-817c-419f-a0c0-660854dc7cbe = trusted
+# (for Music bei Jean (Willikins) [willikins])
+trust 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = trusted
+# (for Music bei Jean (Willikins Clone))
+trust 6e3431e9-8ec2-404a-9c35-b967db63147d = trusted
+# (for Music bei Jean (Watson))
+trust a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = trusted
+# (for )
+trust dafe9a64-2480-40e2-9688-9f783577ef72 = dead
+# (for web)
+#trust 00000000-0000-0000-0000-000000000001 = semitrusted
+# (for music transfer via rsync.net [music_rsync])
+#trust 83c42610-42ad-459d-92a4-1aca2dfb97e1 = semitrusted
+
+# Repository groups
+# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted)
+# (Separate group names with spaces)
+# (for Music bei Jean (Willikins) [willikins])
+group 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = archive
+# (for Music bei Jean (Willikins Clone))
+group 6e3431e9-8ec2-404a-9c35-b967db63147d = archive
+# (for )
+group 26d38f31-cb6c-412c-84ef-597d7959a680 = backup
+# (for Music bei Pirmin)
+group 0734498b-817c-419f-a0c0-660854dc7cbe = client
+# (for Music bei Jean (Watson))
+group a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = client
+# (for music transfer via rsync.net [music_rsync])
+group 83c42610-42ad-459d-92a4-1aca2dfb97e1 = transfer
+# (for )
+group dafe9a64-2480-40e2-9688-9f783577ef72 = unwanted
+# (for web)
+#group 00000000-0000-0000-0000-000000000001 = 
+
+# Repository preferred contents
+# (Set to "standard" to use a repository's group's preferred contents)
+# (for Music bei Jean (Willikins) [willikins])
+wanted 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = (not (copies=archive:2 or copies=smallarchive:2)) or approxlackingcopies=2
+# (for Music bei Jean (Willikins Clone))
+wanted 6e3431e9-8ec2-404a-9c35-b967db63147d = (not (copies=archive:2 or copies=smallarchive:2)) or approxlackingcopies=2
+# (for music transfer via rsync.net [music_rsync])
+wanted 83c42610-42ad-459d-92a4-1aca2dfb97e1 = not (inallgroup=client and copies=archive:2 and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
+# (for Music bei Pirmin)
+wanted 0734498b-817c-419f-a0c0-660854dc7cbe = standard
+# (for )
+wanted 26d38f31-cb6c-412c-84ef-597d7959a680 = standard
+# (for )
+wanted dafe9a64-2480-40e2-9688-9f783577ef72 = standard
+# (for web)
+#wanted 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Jean (Watson))
+wanted a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = standard
+
+# Group preferred contents
+# (Used by repositories with "groupwanted" in their preferred contents)
+#groupwanted archive = 
+#groupwanted backup = 
+#groupwanted client = 
+#groupwanted incrementalbackup = 
+#groupwanted manual = 
+#groupwanted public = 
+#groupwanted smallarchive = 
+#groupwanted source = 
+#groupwanted transfer = 
+#groupwanted unwanted = 
+
+# Standard preferred contents
+# (Used by wanted or groupwanted expressions containing "standard")
+# (For reference only; built-in and cannot be changed!)
+# standard client = (((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1
+# standard transfer = (not (inallgroup=client and copies=client:2) and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)) or approxlackingcopies=1
+# standard backup = include=* or unused
+# standard incrementalbackup = ((include=* or unused) and (not copies=incrementalbackup:1)) or approxlackingcopies=1
+# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1
+# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1
+# standard source = not (copies=1)
+# standard manual = present and ((((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or approxlackingcopies=1)
+# standard public = inpreferreddir
+# standard unwanted = exclude=*
+
+# Repository required contents
+# (for web)
+#required 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Pirmin)
+#required 0734498b-817c-419f-a0c0-660854dc7cbe = 
+# (for Music bei Jean (Willikins) [willikins])
+#required 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = 
+# (for Music bei Jean (Willikins Clone))
+#required 6e3431e9-8ec2-404a-9c35-b967db63147d = 
+# (for music transfer via rsync.net [music_rsync])
+#required 83c42610-42ad-459d-92a4-1aca2dfb97e1 = 
+# (for Music bei Jean (Watson))
+#required a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 = 
+
+# Scheduled activities
+# (Separate multiple activities with "; ")
+# (for web)
+#schedule 00000000-0000-0000-0000-000000000001 = 
+# (for Music bei Pirmin)
+#schedule 0734498b-817c-419f-a0c0-660854dc7cbe = 
+# (for Music bei Jean (Willikins) [willikins])
+#schedule 20e9d2e5-9563-4507-82d5-bf8e23be29a5 = 
+# (for Music bei Jean (Willikins Clone))
+#schedule 6e3431e9-8ec2-404a-9c35-b967db63147d = 
+# (for music transfer via rsync.net [music_rsync])
+#schedule 83c42610-42ad-459d-92a4-1aca2dfb97e1 = 
+# (for Music bei Jean (Watson))
+#schedule a6febfa0-9fe5-4a65-95bb-dc255d87c2e2 =
+# End of transcript or log.
+"""]]

Added a comment
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_5_00926da970a20de67ba7719610f17142._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_5_00926da970a20de67ba7719610f17142._comment
new file mode 100644
index 0000000..5873167
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_5_00926da970a20de67ba7719610f17142._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 5"
+ date="2014-08-31T10:15:30Z"
+ content="""
+I have found out that there is a connection between this problem and the _global_ configuration of `annex.alwayscommit`. This problem will appear only if `annex.alwayscommit` is globally set to `false`. What is very strange is that setting `annex.alwayscommit` locally does not make this bug appear; only a globally set `annex.alwayscommit` will trigger this problem.
+
+I fixed the test script to set `annex.alwayscommit` globally.
+
+Now I see why I could reproduce this bug on different machines but Joey could not: all my machines have the same `~/.gitconfig`.
+"""]]

Add details to the description
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
index 92ce0aa..701876c 100644
--- a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
@@ -1,6 +1,6 @@
 ### Please describe the problem.
 
-`git annex whereis` says that there are no copies of any of the files that have been added in repositories running in direct mode.
+`git annex whereis` says that there are no copies of any of the files that have been added in repositories running in direct mode when `annex.alwayscommit` is set to `false`.
 
 In other words, if I add a file from PC1 in direct mode, `whereis` in PC2 will fail. Instead, if I add the same file from PC1 in indirect mode, `whereis` in PC2 will work correctly and will report that the file is present in PC1.
 

Add global configuration to test script
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
index 69302b0..92ce0aa 100644
--- a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
@@ -20,7 +20,10 @@ The following script (available at <https://gist.github.com/gioele/dde462df89edf
  
 set -e ; set -u
 export LC_ALL=C
- 
+
+# alwayscommit must be set globally to affects whereis and sync
+git config --global annex.alwayscommit false 
+
 direct=true # set to false to make the problem disappear
  
 h=${h:-localhost}

Added a comment
diff --git a/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment b/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment
new file mode 100644
index 0000000..e58f540
--- /dev/null
+++ b/doc/forum/difference_between_full_backup_and_number_of_copies__63__/comment_1_df1850059a7a3006db7cb5c588dac3d7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8wY171R5c4u_jPmB6LU6n6Px2xePM4sE"
+ nickname="Efraim"
+ subject="comment 1"
+ date="2014-08-31T07:09:52Z"
+ content="""
+number of copies is the minimum number of copies that can exist when you try to drop a file from a repository/without git-annex telling you that you don't have enough copies and should protect your data better.  A full backup by default tries to get every file it can get its hands on, including old versions.
+"""]]

diff --git a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn
index 5522add..f8baa3b 100644
--- a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn
+++ b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn
@@ -292,4 +292,4 @@ shell@hammerhead:/sdcard/git-annex.home $ ^D
 shell@hammerhead:/ $
 """]]
 
-Android is new for me, so it's possible I'm must doing something utterly wrong.
+Android is new to me, so it's possible I'm doing something utterly wrong.

diff --git a/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn
new file mode 100644
index 0000000..5522add
--- /dev/null
+++ b/doc/bugs/Android_4.4_install_fails_with_permission_denied_errors.mdwn
@@ -0,0 +1,295 @@
+### Please describe the problem.
+
+Installing git-annex on a new Nexus 5 with Android 4.4.4 using [Android 4.4 and 4.3 git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/4.3/git-annex.apk) does not give me a working git-annex environment. It seems permission is denied to install many of the app files.
+
+
+### What steps will reproduce the problem?
+
+1. Install git-annex
+2. From within `adb shell`, run: `/data/data/ga.androidterm/runshell`
+3. Try one of the included programs, e.g., `git`
+
+
+### What version of git-annex are you using? On what operating system?
+
+The current (as of 2014-08-30) git-annex for Android 4.3 and up on Android 4.4.4.
+
+
+### Please provide any additional information below.
+
+Running `/data/data/ga.androidterm/runshell` from `adb shell` gives me:
+
+[[!format txt """
+shell@hammerhead:/ $ /data/data/ga.androidterm/runshell                        
+Falling back to hardcoded app location; cannot find expected files in /data/app-lib
+shell@hammerhead:/sdcard/git-annex.home $ ls
+git-annex-install.log
+shell@hammerhead:/sdcard/git-annex.home $ cat git-annex-install.log
+Installation starting to /data/data/ga.androidterm
+71c22504d777380dd59d2128b97715fde9ef6bec
+mv: can't rename '/data/data/ga.androidterm/bin': Permission denied
+installing busybox
+ln: /data/data/ga.androidterm/bin/busybox: Permission denied
+installing git-annex
+ln: /data/data/ga.androidterm/bin/git-annex: Permission denied
+installing git-shell
+ln: /data/data/ga.androidterm/bin/git-shell: Permission denied
+installing git-upload-pack
+ln: /data/data/ga.androidterm/bin/git-upload-pack: Permission denied
+installing git
+ln: /data/data/ga.androidterm/bin/git: Permission denied
+installing gpg
+ln: /data/data/ga.androidterm/bin/gpg: Permission denied
+installing rsync
+ln: /data/data/ga.androidterm/bin/rsync: Permission denied
+installing ssh
+ln: /data/data/ga.androidterm/bin/ssh: Permission denied
+installing ssh-keygen
+ln: /data/data/ga.androidterm/bin/ssh-keygen: Permission denied
+busybox: /data/data/ga.androidterm/bin/[: Permission denied
+busybox: /data/data/ga.androidterm/bin/[[: Permission denied
+busybox: /data/data/ga.androidterm/bin/ar: Permission denied
+busybox: /data/data/ga.androidterm/bin/arp: Permission denied
+busybox: /data/data/ga.androidterm/bin/ash: Permission denied
+busybox: /data/data/ga.androidterm/bin/base64: Permission denied
+busybox: /data/data/ga.androidterm/bin/basename: Permission denied
+busybox: /data/data/ga.androidterm/bin/beep: Permission denied
+busybox: /data/data/ga.androidterm/bin/blkid: Permission denied
+busybox: /data/data/ga.androidterm/bin/blockdev: Permission denied
+busybox: /data/data/ga.androidterm/bin/bunzip2: Permission denied
+busybox: /data/data/ga.androidterm/bin/bzcat: Permission denied
+busybox: /data/data/ga.androidterm/bin/bzip2: Permission denied
+busybox: /data/data/ga.androidterm/bin/cal: Permission denied
+busybox: /data/data/ga.androidterm/bin/cat: Permission denied
+busybox: /data/data/ga.androidterm/bin/catv: Permission denied
+busybox: /data/data/ga.androidterm/bin/chat: Permission denied
+busybox: /data/data/ga.androidterm/bin/chattr: Permission denied
+busybox: /data/data/ga.androidterm/bin/chgrp: Permission denied
+busybox: /data/data/ga.androidterm/bin/chmod: Permission denied
+busybox: /data/data/ga.androidterm/bin/chown: Permission denied
+busybox: /data/data/ga.androidterm/bin/chpst: Permission denied
+busybox: /data/data/ga.androidterm/bin/chroot: Permission denied
+busybox: /data/data/ga.androidterm/bin/chrt: Permission denied
+busybox: /data/data/ga.androidterm/bin/chvt: Permission denied
+busybox: /data/data/ga.androidterm/bin/cksum: Permission denied
+busybox: /data/data/ga.androidterm/bin/clear: Permission denied
+busybox: /data/data/ga.androidterm/bin/cmp: Permission denied
+busybox: /data/data/ga.androidterm/bin/comm: Permission denied
+busybox: /data/data/ga.androidterm/bin/cp: Permission denied
+busybox: /data/data/ga.androidterm/bin/cpio: Permission denied
+busybox: /data/data/ga.androidterm/bin/cttyhack: Permission denied
+busybox: /data/data/ga.androidterm/bin/cut: Permission denied
+busybox: /data/data/ga.androidterm/bin/dc: Permission denied
+busybox: /data/data/ga.androidterm/bin/dd: Permission denied
+busybox: /data/data/ga.androidterm/bin/deallocvt: Permission denied
+busybox: /data/data/ga.androidterm/bin/devmem: Permission denied
+busybox: /data/data/ga.androidterm/bin/diff: Permission denied
+busybox: /data/data/ga.androidterm/bin/dirname: Permission denied
+busybox: /data/data/ga.androidterm/bin/dmesg: Permission denied
+busybox: /data/data/ga.androidterm/bin/dnsd: Permission denied
+busybox: /data/data/ga.androidterm/bin/dos2unix: Permission denied
+busybox: /data/data/ga.androidterm/bin/dpkg: Permission denied
+busybox: /data/data/ga.androidterm/bin/dpkg-deb: Permission denied
+busybox: /data/data/ga.androidterm/bin/du: Permission denied
+busybox: /data/data/ga.androidterm/bin/dumpkmap: Permission denied
+busybox: /data/data/ga.androidterm/bin/echo: Permission denied
+busybox: /data/data/ga.androidterm/bin/envdir: Permission denied
+busybox: /data/data/ga.androidterm/bin/envuidgid: Permission denied
+busybox: /data/data/ga.androidterm/bin/expand: Permission denied
+busybox: /data/data/ga.androidterm/bin/fakeidentd: Permission denied
+busybox: /data/data/ga.androidterm/bin/false: Permission denied
+busybox: /data/data/ga.androidterm/bin/fbset: Permission denied
+busybox: /data/data/ga.androidterm/bin/fbsplash: Permission denied
+busybox: /data/data/ga.androidterm/bin/fdflush: Permission denied
+busybox: /data/data/ga.androidterm/bin/fdformat: Permission denied
+busybox: /data/data/ga.androidterm/bin/fdisk: Permission denied
+busybox: /data/data/ga.androidterm/bin/fgconsole: Permission denied
+busybox: /data/data/ga.androidterm/bin/find: Permission denied
+busybox: /data/data/ga.androidterm/bin/findfs: Permission denied
+busybox: /data/data/ga.androidterm/bin/flash_lock: Permission denied
+busybox: /data/data/ga.androidterm/bin/flash_unlock: Permission denied
+busybox: /data/data/ga.androidterm/bin/flashcp: Permission denied
+busybox: /data/data/ga.androidterm/bin/flock: Permission denied
+busybox: /data/data/ga.androidterm/bin/fold: Permission denied
+busybox: /data/data/ga.androidterm/bin/freeramdisk: Permission denied
+busybox: /data/data/ga.androidterm/bin/ftpd: Permission denied
+busybox: /data/data/ga.androidterm/bin/ftpget: Permission denied
+busybox: /data/data/ga.androidterm/bin/ftpput: Permission denied
+busybox: /data/data/ga.androidterm/bin/fuser: Permission denied
+busybox: /data/data/ga.androidterm/bin/getopt: Permission denied
+busybox: /data/data/ga.androidterm/bin/grep: Permission denied
+busybox: /data/data/ga.androidterm/bin/gunzip: Permission denied
+busybox: /data/data/ga.androidterm/bin/gzip: Permission denied
+busybox: /data/data/ga.androidterm/bin/hd: Permission denied
+busybox: /data/data/ga.androidterm/bin/hdparm: Permission denied
+busybox: /data/data/ga.androidterm/bin/head: Permission denied
+busybox: /data/data/ga.androidterm/bin/hexdump: Permission denied
+busybox: /data/data/ga.androidterm/bin/httpd: Permission denied
+busybox: /data/data/ga.androidterm/bin/ifconfig: Permission denied
+busybox: /data/data/ga.androidterm/bin/ifdown: Permission denied
+busybox: /data/data/ga.androidterm/bin/ifup: Permission denied
+busybox: /data/data/ga.androidterm/bin/inotifyd: Permission denied
+busybox: /data/data/ga.androidterm/bin/install: Permission denied
+busybox: /data/data/ga.androidterm/bin/iostat: Permission denied
+busybox: /data/data/ga.androidterm/bin/ip: Permission denied
+busybox: /data/data/ga.androidterm/bin/ipaddr: Permission denied
+busybox: /data/data/ga.androidterm/bin/ipcalc: Permission denied
+busybox: /data/data/ga.androidterm/bin/iplink: Permission denied
+busybox: /data/data/ga.androidterm/bin/iproute: Permission denied
+busybox: /data/data/ga.androidterm/bin/iprule: Permission denied
+busybox: /data/data/ga.androidterm/bin/iptunnel: Permission denied
+busybox: /data/data/ga.androidterm/bin/klogd: Permission denied
+busybox: /data/data/ga.androidterm/bin/ln: Permission denied
+busybox: /data/data/ga.androidterm/bin/loadkmap: Permission denied
+busybox: /data/data/ga.androidterm/bin/losetup: Permission denied
+busybox: /data/data/ga.androidterm/bin/lpd: Permission denied
+busybox: /data/data/ga.androidterm/bin/lpq: Permission denied
+busybox: /data/data/ga.androidterm/bin/lpr: Permission denied
+busybox: /data/data/ga.androidterm/bin/ls: Permission denied
+busybox: /data/data/ga.androidterm/bin/lsattr: Permission denied
+busybox: /data/data/ga.androidterm/bin/lsof: Permission denied
+busybox: /data/data/ga.androidterm/bin/lspci: Permission denied
+busybox: /data/data/ga.androidterm/bin/lsusb: Permission denied
+busybox: /data/data/ga.androidterm/bin/lzcat: Permission denied
+busybox: /data/data/ga.androidterm/bin/lzma: Permission denied
+busybox: /data/data/ga.androidterm/bin/lzop: Permission denied
+busybox: /data/data/ga.androidterm/bin/lzopcat: Permission denied
+busybox: /data/data/ga.androidterm/bin/makedevs: Permission denied
+busybox: /data/data/ga.androidterm/bin/makemime: Permission denied
+busybox: /data/data/ga.androidterm/bin/man: Permission denied
+busybox: /data/data/ga.androidterm/bin/md5sum: Permission denied
+busybox: /data/data/ga.androidterm/bin/mkdir: Permission denied
+busybox: /data/data/ga.androidterm/bin/mkfifo: Permission denied
+busybox: /data/data/ga.androidterm/bin/mknod: Permission denied
+busybox: /data/data/ga.androidterm/bin/mkswap: Permission denied
+busybox: /data/data/ga.androidterm/bin/mktemp: Permission denied
+busybox: /data/data/ga.androidterm/bin/more: Permission denied
+busybox: /data/data/ga.androidterm/bin/mpstat: Permission denied
+busybox: /data/data/ga.androidterm/bin/mv: Permission denied
+busybox: /data/data/ga.androidterm/bin/nbd-client: Permission denied
+busybox: /data/data/ga.androidterm/bin/nc: Permission denied
+busybox: /data/data/ga.androidterm/bin/netstat: Permission denied
+busybox: /data/data/ga.androidterm/bin/nice: Permission denied
+busybox: /data/data/ga.androidterm/bin/nmeter: Permission denied
+busybox: /data/data/ga.androidterm/bin/nohup: Permission denied
+busybox: /data/data/ga.androidterm/bin/od: Permission denied
+busybox: /data/data/ga.androidterm/bin/openvt: Permission denied
+busybox: /data/data/ga.androidterm/bin/patch: Permission denied
+busybox: /data/data/ga.androidterm/bin/pidof: Permission denied
+busybox: /data/data/ga.androidterm/bin/pipe_progress: Permission denied
+busybox: /data/data/ga.androidterm/bin/pmap: Permission denied
+busybox: /data/data/ga.androidterm/bin/popmaildir: Permission denied
+busybox: /data/data/ga.androidterm/bin/printenv: Permission denied
+busybox: /data/data/ga.androidterm/bin/printf: Permission denied
+busybox: /data/data/ga.androidterm/bin/pscan: Permission denied
+busybox: /data/data/ga.androidterm/bin/pstree: Permission denied
+busybox: /data/data/ga.androidterm/bin/pwd: Permission denied
+busybox: /data/data/ga.androidterm/bin/pwdx: Permission denied
+busybox: /data/data/ga.androidterm/bin/raidautorun: Permission denied
+busybox: /data/data/ga.androidterm/bin/rdev: Permission denied
+busybox: /data/data/ga.androidterm/bin/readlink: Permission denied
+busybox: /data/data/ga.androidterm/bin/readprofile: Permission denied
+busybox: /data/data/ga.androidterm/bin/realpath: Permission denied
+busybox: /data/data/ga.androidterm/bin/reformime: Permission denied
+busybox: /data/data/ga.androidterm/bin/renice: Permission denied

(Diff truncated)
diff --git a/doc/bugs/Upload_to_S3_fails_.mdwn b/doc/bugs/Upload_to_S3_fails_.mdwn
new file mode 100644
index 0000000..2264c42
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+
+Uploading a 21GB file to an S3 special remote fails. It will generally fail somewhere at about 3-15%. I am using the new chunking feature, with chunks set to 25MiB.
+
+### What steps will reproduce the problem?
+
+    $ git annex copy my-big-file.tar.bz --to s3
+    copy my-big-file.tar.bz (gpg) (checking s3...) (to s3...)
+    13%       863.8KB/s 6h0m
+      ErrorClosed
+    failed
+    git-annex: copy: 1 failed
+
+### What version of git-annex are you using? On what operating system?
+
+Running on Arch Linux.
+
+    git-annex version: 5.20140818-g10bf03a
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+If I fire up the web app and open the log, the end looks like this:
+
+
+[[!format sh """
+...
+
+3%       857.3KB/s 6h46m
+3%       857.3KB/s 6h46m
+3%       857.3KB/s 6h46m
+3%       857.4KB/s 6h46m
+3%       857.4KB/s 6h46m
+3%       857.5KB/s 6h46m
+3%       857.5KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.6KB/s 6h46m
+3%       857.7KB/s 6h46m
+3%       857.7KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.8KB/s 6h46m
+3%       857.9KB/s 6h46m
+3%       857.9KB/s 6h46m
+3%       858.0KB/s 6h46m
+3%       858.0KB/s 6h46m
+3%       858.1KB/s 6h46m
+3%       858.1KB/s 6h45m
+3%       858.1KB/s 6h45mmux_client_request_session: read from master failed: Broken pipe
+
+"""]]

diff --git a/doc/todo/wishlist:_provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn b/doc/todo/wishlist:_provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn
new file mode 100644
index 0000000..ab4e488
--- /dev/null
+++ b/doc/todo/wishlist:_provide_a_config_option_for_using_new_hashing_scheme_in_non-bare_remotes.mdwn
@@ -0,0 +1 @@
+I understand that for backwards compatibility the non-bare remotes use the old "mixed" case scheme. However, for new annexes, it'd make sense to be able to use the new one so the scheme matches in all remotes.

Added a comment
diff --git a/doc/bugs/ssh_over_IPv6/comment_1_0287f73c44645a1f854ecfe4ddddb258._comment b/doc/bugs/ssh_over_IPv6/comment_1_0287f73c44645a1f854ecfe4ddddb258._comment
new file mode 100644
index 0000000..13c9794
--- /dev/null
+++ b/doc/bugs/ssh_over_IPv6/comment_1_0287f73c44645a1f854ecfe4ddddb258._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2014-08-28T20:46:29Z"
+ content="""
+
+Try using ~/.ssh/config as a workaround
+
+    Host myserver
+    Hostname fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e
+
+then just tell git-annex to use myserver
+
+"""]]

removed
diff --git a/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment b/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment
deleted file mode 100644
index 8c6a866..0000000
--- a/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
- nickname="Justin"
- subject="comment 1"
- date="2014-08-28T20:45:10Z"
- content="""
-Try using ~/.ssh/config as a workaround
-
-Host myserver
-Hostname fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e
-
-then just tell git-annex to use myserver
-"""]]

Added a comment
diff --git a/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment b/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment
new file mode 100644
index 0000000..8c6a866
--- /dev/null
+++ b/doc/bugs/ssh_over_IPv6/comment_1_cfff036345e1d4995655de6cf636ad73._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2014-08-28T20:45:10Z"
+ content="""
+Try using ~/.ssh/config as a workaround
+
+Host myserver
+Hostname fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e
+
+then just tell git-annex to use myserver
+"""]]

diff --git a/doc/bugs/ssh_over_IPv6.mdwn b/doc/bugs/ssh_over_IPv6.mdwn
index ea2a4c8..d4f2e70 100644
--- a/doc/bugs/ssh_over_IPv6.mdwn
+++ b/doc/bugs/ssh_over_IPv6.mdwn
@@ -9,6 +9,7 @@ When i try to sync to my server (path in .git/config is "[fcb8:b10:1cb8:c94:58d0
 5. git annex sync
 
 ### What version of git-annex are you using? On what operating system?
+```
 git-annex version: 5.20140412ubuntu1
 build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
 key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
@@ -16,13 +17,4 @@ remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook ex
 local repository version: 5
 supported repository version: 5
 upgrade supported from repository versions: 0 1 2 4
-
-### Please provide any additional information below.
-
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
+```

diff --git a/doc/bugs/ssh_over_IPv6.mdwn b/doc/bugs/ssh_over_IPv6.mdwn
new file mode 100644
index 0000000..ea2a4c8
--- /dev/null
+++ b/doc/bugs/ssh_over_IPv6.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+When i try to sync to my server (path in .git/config is "[fcb8:b10:1cb8:c94:58d0:2522:89f9:c89e]:/home/thomas/git/musik") the url gets messed up by annex and i get the error "git-annex: bad url ssh://[fcb8/~/b10:1cb8:c94:58d0:2522:89f9:c89e]:/home/thomas/git/musik".
+
+### What steps will reproduce the problem?
+1. init git & annex
+2. add files
+3. add a IPv6 address remote
+4. push git branches
+5. git annex sync
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 5.20140412ubuntu1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

diff --git a/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn b/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn
new file mode 100644
index 0000000..4223a2d
--- /dev/null
+++ b/doc/forum/difference_between_full_backup_and_number_of_copies__63__.mdwn
@@ -0,0 +1,9 @@
+If I have three repositories setup in the git annex webui as:
+
+full backup,
+
+and every file put into one of the repos seems to be propagated to the other two,
+
+what is the usage of the setting "number of copies" which is default to 1 but can be increased to 2 or 3? Does this setting matter in this context?
+
+I'm using assistant version 5.20140517.4

Added a comment
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment
new file mode 100644
index 0000000..41f28a0
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas/comment_1_a8effe196e4a040630d183803768c5a1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="anders7788"
+ ip="212.247.195.173"
+ subject="comment 1"
+ date="2014-08-27T06:59:08Z"
+ content="""
+My version is:
+
+assistant version 5.20140517.4
+"""]]

help
diff --git a/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn
new file mode 100644
index 0000000..e71bf04
--- /dev/null
+++ b/doc/forum/Attempting_to_repair_fails_with_everincreasing_deltas.mdwn
@@ -0,0 +1,21 @@
+Hello,
+
+I am using the latest git-annex with the webui having two local folders (one over nfs) connected as a full backup group. 
+
+On every reboot I get a jumping ball icon with the text:
+
+"Attempting to repair [tr2]"
+
+And the later the text:
+
+"failed to sync to tr2"
+
+The debug log is filled with entries like this, where the number of deltas is increasing:
+
+[2014-08-26 20:34:50 CEST] PushRetrier: Syncing with tr2 
+fatal: pack has 15 unresolved deltas
+error: unpack failed: index-pack abnormal exit
+To /nfs/backup
+ ! [remote rejected] git-annex -> synced/git-annex (n/a (unpacker error))
+ ! [remote rejected] annex/direct/master -> synced/master (n/a (unpacker error))
+error: failed to push some refs to '/nfs/backup''

diff --git a/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
index 730df1d..cf5e413 100644
--- a/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
+++ b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
@@ -1,5 +1,5 @@
 ### Please describe the problem.
-When pairing with xmpp buddys, the well does not expand to fit the whole buddy list
+When pairing with xmpp buddies, the well does not expand to fit the whole buddy list
 
 ### What steps will reproduce the problem?
 Go to the pairing menu

Added visual bug description
diff --git a/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
new file mode 100644
index 0000000..730df1d
--- /dev/null
+++ b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
@@ -0,0 +1,12 @@
+### Please describe the problem.
+When pairing with xmpp buddys, the well does not expand to fit the whole buddy list
+
+### What steps will reproduce the problem?
+Go to the pairing menu
+
+### What version of git-annex are you using? On what operating system?
+ 5.20140717 from the homebrew bottle
+
+### Please provide any additional information below.
+
+![image of bug](http://i.imgur.com/fZe1ERD.png)

diff --git a/doc/todo/merge_in_ram___40__disk__41____63__.mdwn b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
new file mode 100644
index 0000000..a4a698a
--- /dev/null
+++ b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
@@ -0,0 +1,5 @@
+git-annex is great. But for my repos the merge and recording state operations take forever.
+
+(merging fotos_enc_pg/synced/git-annex into git-annex...)
+
+Since git-annex is another branch (than master) and git usually needs a worktree for merging I assume that git-annex branch is temporarily checked out somewhere. Would it be possible to move this operation to RAM? Or a RAM-Disk?

Added a comment: How I solved it...
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
new file mode 100644
index 0000000..e58191a
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.166"
+ subject="How I solved it..."
+ date="2014-08-26T23:03:09Z"
+ content="""
+I decided it was a bit harsh, so I removed comment. Here is how I solved problem:
+
+I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways.
+"""]]

diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
index 1f4f498..8d3c840 100644
--- a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
+++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
@@ -1,3 +1,5 @@
 I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along?
 
 (If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service)
+
+[Edit: It may be easier to just use Git-Annex (no assistant), so that works too]

diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
new file mode 100644
index 0000000..1f4f498
--- /dev/null
+++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
@@ -0,0 +1,3 @@
+I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along?
+
+(If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service)

Added a comment: path on windows
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment
new file mode 100644
index 0000000..4cbf0ea
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBmv0HhwTFxkpxlf8ifTlMOHnIwHCHTYs"
+ nickname="y"
+ subject="path on windows"
+ date="2014-08-26T12:18:39Z"
+ content="""
+To add to my comment I also installed git-annex in the same directory as the msys git distrib in both cases.
+"""]]

Added a comment: Relying on path is not best practice in a Windows environment
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment
new file mode 100644
index 0000000..42537f9
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Relying on path is not best practice in a Windows environment"
+ date="2014-08-25T16:16:33Z"
+ content="""
+Unlike under POSIX environments
+generally applications under windows don't add themselves to path,
+or to a directory already in path.
+
+Generally applications announce their location using the registry.
+Under either HKEY_LOCAL_MACHINE\SOFTWARE,
+or in case of software installed for one particular user only
+under HKEY_CURRENT_USER\SOFTWARE.
+
+Git however AFAIK does not.
+Most likely the best thing to do is to prompt the user when installing git-annex
+where git is, and store this variable.
+
+Note that in both my installs I installed git-annex into the git directory,
+and the git-annex webapp still couldn't find it. 
+"""]]

Added a comment: Regarding accessing files in a time capsule...
diff --git a/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
new file mode 100644
index 0000000..dbe429f
--- /dev/null
+++ b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~electrichead"
+ nickname="electrichead"
+ subject="Regarding accessing files in a time capsule..."
+ date="2014-08-25T15:51:00Z"
+ content="""
+Imagine a rather contrived doomsday scenario: the file paths and/or basenames are important and, for some reason, the symlinks are not present (perhaps they got deleted, or aren't supported). `git` and `git-annex` no longer exist and let's assume knowledge of `git` internals is not useful here. All the *content* is there, stored under hashed file names under `.git/annex/objects`.
+
+I may be missing something obvious but I think options for restoring file paths include:
+
+  - direct mode bypasses this issue; all the files are right there. 
+  - the WORM backend perhaps carries enough information in the object file names to work with.
+  - file content/metadata may be sufficient to easily recreate a sensible directory structure in some cases, so no worries.
+
+These first two options may represent compromises in various use-cases and the last may not be applicable or, if it is, practical. The object-path mapping could trivially be backed up in plain text in lieu of these. Like I said, I may be overlooking something here that makes this unnecessary or even a non-concern (actually, I've convinced myself it's not a serious concern in most of the use-cases I've considered, but crossing i's and dotting t's).
+"""]]

Added a comment
diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment
new file mode 100644
index 0000000..192d48f
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 2"
+ date="2014-08-24T22:26:47Z"
+ content="""
+Ok, I see, http://git-annex.branchable.com/internals/hashing/ says that old vs new hash mess is deliberate, to make user experience better. (One might ask why one hash was replaced with another equivalent, but nobody would. Oh wait, it's a filesystem case sensitivity issue of course. But it's too secret to be mentioned on \"hashing\" page.)
+
+\"unused --from=\" issue comes and goes, don't see it now. That initial issue of completely broken symlinks happened after running testremote, then breaking it (because it should say it takes hour(s) to complete). So, many users probably won't be affected (nevermind that those who will, will essentially have data loss).
+
+Last issue I faced that somehow my local working copy gets \"bare = true\" each time I sync against remote SSH repo (which is bare of course, as remote repo should be).
+
+"""]]

Added a comment
diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment
new file mode 100644
index 0000000..8ca81d3
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 1"
+ date="2014-08-24T20:27:08Z"
+ content="""
+Aha, so local repo is created with old hash format. But when you add remote (special rsync remote in my case), and copy --to it, it uses new hashes:
+
+~~~~
+copy 20120122 Routing doorbell/IMG_3776.JPG (checking nas-rsync...) (to nas-rsync...) 
+sending incremental file list
+7a6/
+7a6/632/
+7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/
+7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+~~~~
+
+This explains this nonsense:
+
+~~~~
+$ git annex unused --from=nas-rsync
+unused nas-rsync (checking for unused data...) (checking master...) 
+  Some annexed data on nas-rsync is not used by any files:
+    NUMBER  KEY
+    1       SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+    2       SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+    3       SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused --from nas-rsync NUMBER
+  
+ok
+~~~~
+
+"""]]

diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn
new file mode 100644
index 0000000..3933fcb
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn
@@ -0,0 +1,28 @@
+~~~~
+$ git annex version
+git-annex version: 5.20140818-g10bf03a
+~~~~
+
+When repository was initially created, it used "old" hashing from http://git-annex.branchable.com/internals/hashing/ . After some operations, annex was upgraded to "new" format. However, symlinks are still in "old" format and dangling. "git annex fsck", "git annex repair", "git annex pre-commit" - none helps.
+
+~~~~
+$ ls -l pics
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 IMG_3776.JPG -> ../.git/annex/objects/KM/j6/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 renamed2.jpg -> ../.git/annex/objects/7F/z3/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 renamed.jpg -> ../.git/annex/objects/W1/vK/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+
+$ find .git/annex/objects/
+.git/annex/objects/
+.git/annex/objects/219
+.git/annex/objects/219/741
+.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+.git/annex/objects/7a6
+.git/annex/objects/7a6/632
+.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+.git/annex/objects/df3
+.git/annex/objects/df3/9a8
+.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+~~~~

Added a comment
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
new file mode 100644
index 0000000..8afa4c6
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T18:31:25Z"
+ content="""
+Previous comment was written in response to a comment suggesting me to rewrite it in Python myself - which was then removed for some reason.
+
+"""]]

Added a comment
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
new file mode 100644
index 0000000..8e613dd
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 3"
+ date="2014-08-24T18:29:23Z"
+ content="""
+Sure, that's the plan. But first I'm doing my homework to understand how it got to that and how community copes with that. Maybe I don't get something and every open-source project should have a notice like: \"Installation from scratch. This is not recommended.\" (http://git-annex.branchable.com/install/). Interested in building software you run? Interested to help? Get lost, you won't get it. Am I surprised? Nope, I'm doing my homework and know where that Haskell thing came from. A piece of Microsoft was largely involved with it, so no surprise of such attitudes.
+
+Surely I'm not the only one who got jaundiced eye on git-annex: https://github.com/tv42/big : \"big is not like git-annex, because: it's not written in Haskell, so it might even work across distribution upgrades and platforms\". Certainly, stories of cvsup and unison, which are now where they should be - rest in peace, didn't help. So, once again, I'm interested to know how other people deal with this lack of proper compilation instructions, ability to get simple and easy tweaks, etc. - short of not using it, which seems to be a popular choice, despite all the git-annex coolness (I for one have been having its deployment in my queue fro half a year, instead of spending exactly a weekend to do tweaks I need and contribute them back).
+
+
+"""]]

removed
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment
deleted file mode 100644
index f65788e..0000000
--- a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="Ganwell"
- ip="46.14.43.36"
- subject="Project for Paul"
- date="2014-08-24T16:48:32Z"
- content="""
-Hi Paul
-
-I just found a weekend project for you: rewrite git-annex in Python. Let me know when you're done.
-
-Best, Jean-Louis
-"""]]

Added a comment: Project for Paul
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment
new file mode 100644
index 0000000..f65788e
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_f0270392af15f219a76add333316965f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="46.14.43.36"
+ subject="Project for Paul"
+ date="2014-08-24T16:48:32Z"
+ content="""
+Hi Paul
+
+I just found a weekend project for you: rewrite git-annex in Python. Let me know when you're done.
+
+Best, Jean-Louis
+"""]]

Added a comment
diff --git a/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
new file mode 100644
index 0000000..66615da
--- /dev/null
+++ b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T11:53:11Z"
+ content="""
+@azul, thanks for hints, but it still fails. No wonders though - this is Haskell, kids.
+
+~~~~
+$ cabal install git-annex --only-dependencies
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+trying: git-annex-5.20140817
+trying: git-annex-5.20140817:+webapp
+trying: git-annex-5.20140817:+s3
+trying: git-annex-5.20140817:+dns
+trying: dns-1.4.3
+trying: yesod-1.2.6.1
+trying: yesod-auth-1.3.4.2
+trying: http-client-0.3.7.1
+trying: http-client-0.3.7.1:+network-uri
+trying: hS3-0.5.8
+trying: hxt-9.3.1.6
+trying: hxt-9.3.1.6:-network-uri
+rejecting: network-2.6.0.1, 2.6.0.0 (conflict: hxt-9.3.1.6:network-uri =>
+network>=2.4 && <2.6)
+rejecting: network-2.5.0.0, 2.4.2.3, 2.4.2.2, 2.4.2.1, 2.4.2.0, 2.4.1.2,
+2.4.1.1, 2.4.1.0, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.1, 2.3.1.0, 2.3.0.14,
+2.3.0.13, 2.3.0.12, 2.3.0.11, 2.3.0.10, 2.3.0.9, 2.3.0.8, 2.3.0.7, 2.3.0.6,
+2.3.0.5, 2.3.0.4, 2.3.0.3, 2.3.0.2, 2.3.0.1, 2.3 (conflict:
+http-client-0.3.7.1:network-uri => network>=2.6)
+rejecting: network-2.2.3.1, 2.2.3, 2.2.1.10, 2.2.1.9, 2.2.1.8, 2.2.1.7,
+2.2.1.6, 2.2.1.5, 2.2.1.4, 2.2.1.3, 2.2.1.2, 2.2.1.1, 2.2.1, 2.2.0.1, 2.2.0.0,
+2.1.0.0, 2.0 (conflict: dns => network>=2.3)
+~~~~
+
+"""]]

Added a comment
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
new file mode 100644
index 0000000..32318b4
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 2"
+ date="2014-08-24T11:04:21Z"
+ content="""
+Python on this system \"just works\". That's because Python is a project with a real community, so if one pundit said \"not supported\", dozen of people shrugged and typed \"make\", then packed up result for thousands to use.
+
+But don't get carried away by OABI, that was just one random example how deployment of git-annex is problematic. There're bigger issues like community involvement, being able to investigate and resolve issues, submit patches, bring new working ideas, make git-annex development and lifecycle sustainable, in the end - as vividly cared by the author.
+
+"""]]

Added a comment
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
new file mode 100644
index 0000000..1cf6c84
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2014-08-24T10:41:58Z"
+ content="""
+> git-annex implementation in a sane, interpreted, \"just works\" language, e.g. Python? Thanks.
+
+Good luck finding anything that works on OARM. Python itself does not support OABI:
+
+> This issue remains as \"won't fix\". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python.
+
+(from <http://bugs.python.org/issue1762561#msg158974>)
+"""]]

diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
new file mode 100644
index 0000000..e091460
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
@@ -0,0 +1 @@
+So, you provide ARM build. But you probably don't know that my NAS box runs OABI. No, you don't know, you can't know, and you shouldn't know. The only thing worth knowing is that writing great software in obscure and esoteric languages drastically limits its usage, impact, and collaboration around it. So, any idea of writing git-annex implementation in a sane, interpreted, "just works" language, e.g. Python? Thanks.

more links
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index d737c84..87f12c9 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -40,8 +40,8 @@
 <h2>OSX Mavericks</h2>
 <iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-mavericks/">
 </iframe>
-<h2>Windows</h2>
+<h2><a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">Windows</a></h2>
 <a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
-<h2>Debian</h2>
+<h2><a href="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">Debian</a></h2>
 <iframe width=1024 scrolling=no height=500px frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
 </iframe>

height3
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index e7772f7..d737c84 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -43,5 +43,5 @@
 <h2>Windows</h2>
 <a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
 <h2>Debian</h2>
-<iframe width=1024 scrolling=no height=200px frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
+<iframe width=1024 scrolling=no height=500px frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
 </iframe>

height2
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index b1c6c05..e7772f7 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -43,5 +43,5 @@
 <h2>Windows</h2>
 <a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
 <h2>Debian</h2>
-<iframe width=1024 scrolling=no height=20em frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
+<iframe width=1024 scrolling=no height=200px frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
 </iframe>

height
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index 1ce724d..b1c6c05 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -43,5 +43,5 @@
 <h2>Windows</h2>
 <a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
 <h2>Debian</h2>
-<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
+<iframe width=1024 scrolling=no height=20em frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
 </iframe>

add debian buildd status
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index b920643..1ce724d 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -42,3 +42,6 @@
 </iframe>
 <h2>Windows</h2>
 <a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
+<h2>Debian</h2>
+<iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
+</iframe>

diff --git a/doc/bugs/tahoe_remote_has_no_repair.mdwn b/doc/bugs/tahoe_remote_has_no_repair.mdwn
new file mode 100644
index 0000000..1f34767
--- /dev/null
+++ b/doc/bugs/tahoe_remote_has_no_repair.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+The tahoe-lafs remote has no built-in way to perform the repair operation.
+This results to data loss if expiration is enabled on the Tahoe grid.
+
+For the current tahoe-lafs release (1.10.0), the only way storage space is freed
+is via garbage collection. Garbage collection removes shares whose lease has expired.
+Data loss will occur if leases are not periodically renewed via
+"tahoe repair --add-lease WRITECAP".
+
+The current implementation of the Tahoe remote in git-annex does not offer a way to
+run lease renewal, and cannot be used on grids where GC is enabled. (GC is not enabled
+in the default configuration, but on private grids it is a sensible option.)
+
+One way renewal could be made easier to do is to add the uploaded files to a directory
+in Tahoe, so that the leases could be easily updated if the directory writecap is known,
+without needing to go through the full list of writecaps for each file stored.
+
+### What steps will reproduce the problem?
+
+1. Use tahoe remote on a tahoe grid where GC is enabled.
+
+2. After GC expiration period, data loss ensues.
+
+### What version of git-annex are you using? On what operating system?
+
+Seems to affect current git master (as of 2014-08-24).

Added a comment: path on windows
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_4_01096994c19b7d0df1cc6866d4f22e21._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_4_01096994c19b7d0df1cc6866d4f22e21._comment
new file mode 100644
index 0000000..5daa87d
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_4_01096994c19b7d0df1cc6866d4f22e21._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBmv0HhwTFxkpxlf8ifTlMOHnIwHCHTYs"
+ nickname="y"
+ subject="path on windows"
+ date="2014-08-23T22:02:07Z"
+ content="""
+I think I have a related problem on win7 sp1. 
+
+When first installing msys git, there's a screen asking for how to set the PATH variable. I chose the option not to update the windows PATH variable, which is the default. Then I installed git annex. Then launching the git-annex-autostart.vbs as well as the webapp one gets an object not found error (on line 2). launching git-annex from git bash with full path yielded an error about not finding git.
+
+Then I proceeded and reinstalled git on top of itself and picked the option to only add git and bash to windows path and it worked.
+"""]]

Added a comment
diff --git a/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment
new file mode 100644
index 0000000..5b26906
--- /dev/null
+++ b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key/comment_1_c8e7be58222afff2a4c1df60f657d2ed._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
+ nickname="Dirk"
+ subject="comment 1"
+ date="2014-08-23T18:13:06Z"
+ content="""
+Restarting the two git-annex instances actually now leads to an error message on computer B.
+
+[[!format sh \"\"\"
+[2014-08-23 20:02:00 CEST] main: starting assistant version 5.20140818-g10bf03a
+[2014-08-23 20:02:00 CEST] Cronner: You should enable consistency checking to protect your data. 
+
+  dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = \"runClient: unable to determine DBUS address\", clientErrorFatal = True})
+[2014-08-23 20:02:00 CEST] TransferScanner: Syncing with C_annex 
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2014-08-23 20:02:00 CEST] Watcher: Performing startup scan
+gcrypt: Development version -- Repository format MAY CHANGE
+(started...) 
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:34:08 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from \"dirk's git-annex encryption key\"
+gcrypt: Packfile 59a8d97d3d252effb044625e020f9dc8621804649186a5c33c4e47f9e961cc1a does not match digest!
+fatal: early EOF
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:34:08 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from \"dirk's git-annex encryption key\"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+   e1d6871..85b70d6  annex/direct/master -> synced/master
+ + e68b5a9...99dc810 git-annex -> synced/git-annex (forced update)
+\"\"\"]]
+"""]]

diff --git a/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn
new file mode 100644
index 0000000..1d4ea21
--- /dev/null
+++ b/doc/bugs/Problem_setting_up_encrypted_repository_using_the_assistant_with___40__outside_of_git-annex__41___shared_pgp_key.mdwn
@@ -0,0 +1,387 @@
+### Please describe the problem.
+Using the assistant on two computers to setup a shared encrypted repository (while sharing the same pgp key) on a third computer leads to files not propagating between one and two.
+
+The first and second computer does not get changes done on the other. If new files are added on the first computer it appears as if everything works (no error messages) but the files never reach the second computer (and vice versa).  
+
+
+### What steps will reproduce the problem?
+
+Three computers needed.
+
+* Computer A: Use the assistant to create a repository
+* Computer A: Use the assitant to setup a remote repository on Computer C (Add another repository - Remote server - Encrypt with GnuPG key/Encript repository with a new encryption key - Save changes)
+
+[At this point files propagate from A to C]
+ 
+* Computer A: Export the private and public gpg keys to files
+* Computer B: Import these private and public gpg files, fix trust to ultimate
+* Computer B: Use the assistant to create a repository
+* Computer B: Use the assitant to connect with the remote repository on Computer C (Add another repository - Remote server - Combine the repositories)
+
+[Files created on A before adding B now appear on B]
+
+[New files created on A do not appear on B, new files created on B do not appear on A. Files from A and B seem to propagate to C (the number of files/directories in the object sub directory on C goes up after adding files on A or B)]
+
+
+
+### What version of git-annex are you using? On what operating system?
+Computer A:
+[[!format sh """
+dirk@A:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 14.04.1 LTS
+Release:	14.04
+Codename:	trusty
+dirk@A:~$ git-annex version
+git-annex version: 5.20140818-g10bf03a
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+dirk@A:~$
+
+dirk@A:~$ gpg --list-keys --list-options show-uid-validity
+/home/dirk/.gnupg/pubring.gpg
+-----------------------------
+pub   4096R/0A7AA2A4 2014-08-23
+uid       [ultimate] dirk's git-annex encryption key
+
+dirk@A:~$ gpg --list-secret-keys --list-options show-uid-validity
+/home/dirk/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/0A7AA2A4 2014-08-23
+uid                  dirk's git-annex encryption key
+
+dirk@A:~$
+"""]]
+
+Computer B:
+[[!format sh """
+dirk@B:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 14.04.1 LTS
+Release:	14.04
+Codename:	trusty
+dirk@B:~$ git-annex version
+git-annex version: 5.20140818-g10bf03a
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+dirk@B:~$
+
+dirk@B:~$ gpg --list-keys --list-options show-uid-validity
+/home/dirk/.gnupg/pubring.gpg
+-----------------------------
+pub   4096R/0A7AA2A4 2014-08-23
+uid       [ultimate] dirk's git-annex encryption key
+
+dirk@B:~$ gpg --list-secret-keys --list-options show-uid-validity
+/home/dirk/.gnupg/secring.gpg
+-----------------------------
+sec   4096R/0A7AA2A4 2014-08-23
+uid                  dirk's git-annex encryption key
+
+dirk@B:~$
+"""]]
+
+Computer C:
+[[!format sh """
+dirk@C:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Debian
+Description:	Debian GNU/Linux 7.6 (wheezy)
+Release:	7.6
+Codename:	wheezy
+dirk@C:~$ git-annex version
+git-annex version: 5.20140717~bpo70+1
+build flags: Assistant Webapp Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
+dirk@C:~$
+"""]]
+
+### Please provide any additional information below.
+
+.git/annex/daemon.log - Computer A
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+[2014-08-23 15:15:01 CEST] main: starting assistant version 5.20140818-g10bf03a
+[2014-08-23 15:15:01 CEST] Cronner: You should enable consistency checking to protect your data. 
+(scanning...) [2014-08-23 15:15:01 CEST] Watcher: Performing startup scan
+(started...) 
+gpg: new configuration file `/home/dirk/.gnupg/gpg.conf' created
+gpg: WARNING: options in `/home/dirk/.gnupg/gpg.conf' are not yet active during this run
+
+Not enough random bytes available.  Please do some other work to give
+the OS a chance to collect more entropy! (Need 235 more bytes)
+....+++++
+
+Not enough random bytes available.  Please do some other work to give
+the OS a chance to collect more entropy! (Need 196 more bytes)
+.......+++++
+gpg: /home/dirk/.gnupg/trustdb.gpg: trustdb created
+gpg: key 0A7AA2A4 marked as ultimately trusted
+Generating public/private rsa key pair.
+Your identification has been saved in /tmp/git-annex-keygen.0/key.
+Your public key has been saved in /tmp/git-annex-keygen.0/key.pub.
+The key fingerprint is:
+7d:02:34:56:d4:86:b6:e5:82:b0:d9:4f:3b:51:b3:c7 dirk@A
+The key's randomart image is:
++--[ RSA 2048]----+
+|        +ooo     |
+|      .o .o *    |
+|       =.o * +   |
+|      o oo= o E  |
+|        Soo+..   |
+|          +o     |
+|           .     |
+|                 |
+|                 |
++-----------------+
+(encryption setup) (hybrid cipher with gpg key 7815EA570A7AA2A4) gcrypt: Development version -- Repository format MAY CHANGE
+gpg: checking the trustdb
+gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
+gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+gcrypt: Repository not found: ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Repository not found: ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+gcrypt: Setting up new repository
+gcrypt: Remote ID is :id:00RaA3cNQu+nZDMERYMM
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ * [new branch]      git-annex -> git-annex
+ok
+[2014-08-23 15:25:46 CEST] main: Syncing with C_annex 
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:45 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:45 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+gcrypt: Encrypting to:  -r 7815EA570A7AA2A4
+gcrypt: Requesting manifest signature
+To gcrypt::ssh://dirk@git-annex-C-dirk_1022_annex/~/annex/
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      annex/direct/master -> synced/master
+[2014-08-23 15:26:46 CEST] Pusher: Syncing with C_annex 
+gcrypt: Development version -- Repository format MAY CHANGE
+gcrypt: Decrypting manifest
+gpg: Signature made Sat 23 Aug 2014 03:25:49 PM CEST using RSA key ID 0A7AA2A4
+gpg: Good signature from "dirk's git-annex encryption key"
+Everything up-to-date
+[2014-08-23 15:34:01 CEST] Committer: Adding hhhhn.txt
+add hhhhn.txt ok
+add hhhhn.txt ok
+[2014-08-23 15:34:01 CEST] Committer: Committing changes to git
+(Recording state in git...)
+[2014-08-23 15:34:01 CEST] Pusher: Syncing with C_annex 
+(Recording state in git...)
+gcrypt: Development version -- Repository format MAY CHANGE
+(gpg) 
+GPGHMACSHA1--7a46226ea53e4043cb45e8df6a2382ac2696164e
+
+             74 100%    0.00kB/s    0:00:00  
+             74 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+[2014-08-23 15:34:01 CEST] Transferrer: Uploaded hhhhn.txt

(Diff truncated)
diff --git a/doc/bugs/webapp_missing_on_redhat.mdwn b/doc/bugs/webapp_missing_on_redhat.mdwn
new file mode 100644
index 0000000..3c16193
--- /dev/null
+++ b/doc/bugs/webapp_missing_on_redhat.mdwn
@@ -0,0 +1,14 @@
+### Please describe the problem.
+I am unable to run the webapp on redhat6.5
+
+### What steps will reproduce the problem?
+yum install git-annex 
+
+### What version of git-annex are you using? On what operating system?
+I am using git-annex version  3.20120523 and on redhat 6.5
+
+### Please provide any additional information below.
+I am seeing the following error when running git annex webapp:
+
+git-annex: unknown command webapp
+

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment
new file mode 100644
index 0000000..ec876d2
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_8_f951981f0bf8cbaecfc46e7b9c903d70._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 8"
+ date="2014-08-22T18:57:37Z"
+ content="""
+I just checked my other large git annex repo and noticed that here too I could no longer add files to the annex. The same observations as above apply. Here too on the tip of the git-anenx branch I had one huge commit in which I dropped the last of the unused WORM keys from another remote. Resetting the git-annex branch to git-annex~1 allowed me to make additions again, even though the reset tip was subsequently merged in again from the remote tracking branch.
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment
new file mode 100644
index 0000000..eb2dea9
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_7_0b6413f9ca403be3d83bb3306d1e7f8f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 7"
+ date="2014-08-22T14:00:42Z"
+ content="""
+I experimented on my snapshot a bit and found out something odd: When I reset the git-annex branch from dda9b06 to git-annex~1 (4246f73) my local file additions succeed, even though git-annex will fast-forward the branch to dda9b06 again before adding (when merging from origin/git-annex). dda9b06 is a large commit in which I dropped many unused WORM keys from another remote.
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment
new file mode 100644
index 0000000..3fcbf20
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_6_e71b251db2ff1f52a40fec40303cdefc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 6"
+ date="2014-08-22T13:15:06Z"
+ content="""
+I tried git annex repair on the repo (before doing any adds). It reports no fsck errors, but the repair then dies from a stack overflow.
+
+[[!format sh \"\"\"
+Running git fsck ...
+No problems found.
+Stack space overflow: current size 8388608 bytes.
+Use `+RTS -Ksize -RTS' to increase it.
+\"\"\"]]
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment
new file mode 100644
index 0000000..0be1eb9
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_5_cc4cba022869b32d298cdafed9545a34._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 5"
+ date="2014-08-22T13:07:34Z"
+ content="""
+I remembered I keep an hourly snapshot regimen and was able to get back the repository from before doing the «add» this morning. Both git fsck and git annex fsck return no errors, and yet, whenever anything is done to the git-annex branch (I tried add and forget), I get the above error.
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment
new file mode 100644
index 0000000..bfab0d1
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_4_522020e71393434834def6c80b82e39e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 4"
+ date="2014-08-22T10:15:51Z"
+ content="""
+The file referred to in the error message seems to be in good shape:
+
+[[!format sh \"\"\"
+git --no-pager show git-annex:000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log
+1408605730.57892s 0 b25f42de-f4be-4d31-84d1-ab0b71dfec01
+1408562938.526946s 0 e148ea91-0eb6-4f47-86e9-db2136a15279
+\"\"\"]]
+
+Strangely, the SHA1 of the blob is different from the one reported in the write-tree error.
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment
new file mode 100644
index 0000000..78e7f41
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_3_1f6443e495cc16a13e2e4175e73dc8f1._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 3"
+ date="2014-08-22T09:58:05Z"
+ content="""
+Doing a git annex fsck on a new clone of the repository succeded; the problem must somehow with the .git/annex/index then, I presume?
+
+I did a git reset to restore to the sane state state before adding, but the problem is that I cannot unannex the files I added. :(
+
+[[!format sh \"\"\"
+nx unannex scrapbook/data/20140822101558/1.jpg
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--head\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"HEAD\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"scrapbook/data/20140822101558/1.jpg\"]
+[2014-08-22 11:56:16 CEST] call: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"commit\",\"-q\",\"--allow-empty\",\"--no-verify\",\"-m\",\"content removed from git annex\"]
+[2014-08-22 11:56:16 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:56:16 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+(Recording state in git...)
+[2014-08-22 11:56:16 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+\"\"\"]]
+
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment
new file mode 100644
index 0000000..b4feb65
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_2_decb1689b8cc2541077e2d0ae273b5e7._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 2"
+ date="2014-08-22T09:38:03Z"
+ content="""
+git commit with git-annex debug output enabled:
+
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff\",\"--cached\",\"--name-only\",\"-z\",\"--diff-filter=ACMRT\",\"--\",\".\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"diff\",\"--name-only\",\"--diff-filter=T\",\"-z\",\"--cached\",\"--\",\".\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"symbolic-ref\",\"HEAD\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"refs/heads/master\"]
+[2014-08-22 11:36:46 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:36:46 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+(Recording state in git...)
+[2014-08-22 11:36:46 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+
+# End of transcript or log.
+\"\"\"]]
+
+"""]]

Added a comment
diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment
new file mode 100644
index 0000000..af980d1
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit/comment_1_2a64a2da445a64149da7335f35142a08._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 1"
+ date="2014-08-22T09:27:34Z"
+ content="""
+git fsck only shows a few dangling blobs from a branch I did earlier and left behind, but otherwise reports no errors.
+
+git annex fsck --fast ultimately fails with the original error message at some point:
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+# nx fsck --fast|egrep -v 'ok$'
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"ls-files\",\"--cached\",\"-z\",\"--\"]
+[2014-08-22 11:14:43 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"git-annex\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-08-22 11:14:43 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"log\",\"refs/heads/git-annex..dda9b068ac5c075e79ab63a531770ad772ae8491\",\"-n1\",\"--pretty=%H\"]
+[2014-08-22 11:14:43 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"cat-file\",\"--batch\"]
+[2014-08-22 11:25:24 CEST] chat: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2014-08-22 11:25:24 CEST] feed: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"update-index\",\"-z\",\"--index-info\"]
+[2014-08-22 11:25:24 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-08-22 11:25:24 CEST] read: git [\"--git-dir=/home/seb/Webmirror/.git\",\"--work-tree=/home/seb/Webmirror\",\"write-tree\"]
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+(Recording state in git...)
+
+# End of transcript or log.
+\"\"\"]]
+
+
+"""]]

diff --git a/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit.mdwn b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit.mdwn
new file mode 100644
index 0000000..fef6e66
--- /dev/null
+++ b/doc/bugs/__34__error:_invalid_object__34____44___after_add__59___cannot_commit.mdwn
@@ -0,0 +1,22 @@
+### Please describe the problem.
+After having added new content (SHA1E backend), when trying to commit, git commit fails with the following error:
+
+[[!format sh """
+(Recording state in git...)
+error: invalid object 100644 5d471129a031f0f493de3736eaea6f2f4056aeee for '000/091/WORM-s1493-m1321288671--scrapbook%data%20111114173520%horiz-menu-tab-r_001.png.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+"""]]
+
+The commit subsequently fails and the index is left as is. When I did git-annex add, I got the same error, but the additions seem to have been staged, at least.
+
+What’s curious about this is that I migrated all keys to SHA1E earlier and dropped all WORM keys. git annex info also says that all my keys are SHA1E.
+
+Can this be related to your changes to the WORM backend? I upgraded to git-annex 5.20140818 today. Rolling back to 5.20140716 didn’t allow me to commit, either, though.
+
+Any way I could resolve this? I don’t want to git reset for now, since this will leave the added objects in the annex store.
+
+### What version of git-annex are you using? On what operating system?
+git-annex 5.20140818
+
+Linux 3.16.1

diff --git a/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000..043a3f2
--- /dev/null
+++ b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,39 @@
+I recently migrated some of my repositories from WORM to SHA1E, and
+noticed after finishing conversion and dropping all WORM keys that
+there are some stale files and directories left over in the
+.git/annex/objects directory. These seem to fall into two categories:
+
+1. There are some empty directories meant for WORM-keys. Strangely, I
+don’t believe the content of these keys has ever been present on this
+machine, and the corresponding .log files do not contain the local
+UUID. What might be the deal with those?
+
+Another set of empty WORM directories housed content I unannexed and
+checked into regular git on my other remote, and then pulled locally.
+A subsequent «dropunused» seems to have left the empty directories
+after dropping their content.
+
+I suppose the stale directories can be safely pruned away?
+
+One thing I noticed is that, while the terminal leaf in the objects
+directory is usually sticky (mode +t), the stale directories to
+content I unannexed are all non-sticky. Maybe this gives some
+indication where things got stuck? A few (though not all) of the other
+terminal directories are non-sticky, as well.
+
+2. There are some .map and .cache files leftover in
+.git/annex/objects. This is an indirect repository, but I briefly
+switched it to direct once. The stale files seem to belong to content
+with which I had some difficulties when «git annex add»’ing the files
+(I recall I had to add them multiple times before they were correctly
+indexed). I now examined these files again and noticed they were
+tracked via regular git. I «git rm»’ed them and readded them into the
+annex. Can the stale .cache and .map files be safely deleted?
+
+I noticed some of these keys have the format
+«WORM-s123-m-123456789--name», with an additional dash before the
+mtime. Has there been a format change, or does this indicate a
+problem?
+
+Best regards,
+Z.

Added a comment: Change the name of the bug
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment
new file mode 100644
index 0000000..ba06cd4
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Change the name of the bug"
+ date="2014-08-21T09:14:16Z"
+ content="""
+I can't seem to change the name of the bug to something more appropriate.
+Maybe you can?
+"""]]

Added a comment: Quite right
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment
new file mode 100644
index 0000000..a4784c6
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Quite right"
+ date="2014-08-21T08:54:50Z"
+ content="""
+Incorrect assumption from my part.
+I reinstalled git into the expected path (C:\program files\Git)
+and the problem is still there.
+
+Running git-annex from command-line works.
+(I tried running git-annex test. It had 23 failed tests,
+most of them because of inability to access the remote: origin.
+But it ran just fine.)
+Running the web-app gives the error listed above.
+"""]]

devblog
diff --git a/doc/devblog/day_218__scary_locking.mdwn b/doc/devblog/day_218__scary_locking.mdwn
new file mode 100644
index 0000000..81afb26
--- /dev/null
+++ b/doc/devblog/day_218__scary_locking.mdwn
@@ -0,0 +1,24 @@
+Plan is to be on vacation and/or low activity this week before DebConf.
+However, today I got involved in fixing a bug that caused the assistant to
+keep files open after syncing with repositories on removable media.
+
+Part of that bug involved lock files not being opend close-on-exec, and
+while fixing that I noticed again that the locking code was scattered all
+around and rather repetitive. That led to a lot of refactoring, which is
+always fun when it involves scary locking code. Thanks goodness for
+referential transparency.
+
+Now there's a Utility.LockFile that works on both POSIX and Windows.
+Howver, that module actually exports very different functions for the two.
+While it might be tempting to try to do a portability layer, the
+two locking models are really very different, and there are lots of gotchas
+such a portability layer would face. The only API that's completely the
+same between the two is dropLock.
+
+This refactoring process and the cleaner, more expressive
+code it led to helped me spot a couple of bugs involving locking. See
+[[!commit e386e26ef207db742da6d406183ab851571047ff]]
+and [[!commit 0a4d301051e4933661b7b0a0791afa95bfe9a1d3]]
+Neither bug has ever seemed to cause
+a problem, but it's nice to be able to spot and fix such bugs before they
+do.

Added a comment: GHC 7.8 Issue
diff --git a/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment b/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
new file mode 100644
index 0000000..7573b47
--- /dev/null
+++ b/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkftzaCvV7EDKVDfJhsQZ3E1Vn-0db516w"
+ nickname="Edward"
+ subject="GHC 7.8 Issue"
+ date="2014-08-20T20:06:01Z"
+ content="""
+Just an FYI: I tried to \"cabal install --only-dependencies\" with GHC 7.8 and it fails because DAV-1.0.1 is pulling in lens-3.10.3 which is not compatible with GHC 7.8 due to changes in Typeable. 
+
+I don't have enough experience with cabal to figure out why it's not trying to use a newer version of lens.
+"""]]

Added a comment
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment
new file mode 100644
index 0000000..f1a170e
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-08-20T14:37:30Z"
+ content="""
+git-annex does not hardcode any paths, and certianly not the path to git. Your system probably does not have the location you installed git added to the PATH. In that case, git-annex may do what windows programs do and look for git.exe in the same directory it was installed into.
+"""]]

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
index 6c2cf84..a1d8ef5 100644
--- a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -11,7 +11,7 @@ You need to install git in order to use git-annex!"
 
 ### What version of git-annex are you using? On what operating system?
 
-Latest git-annex build, from 20140817.
+5.20140817-g71c2250.
 Windows XP.
 
 ### Please provide any additional information below.

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
index 87130a1..6c2cf84 100644
--- a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -11,7 +11,8 @@ You need to install git in order to use git-annex!"
 
 ### What version of git-annex are you using? On what operating system?
 
-Latest windows build, from 20140817
+Latest git-annex build, from 20140817.
+Windows XP.
 
 ### Please provide any additional information below.
 

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
new file mode 100644
index 0000000..87130a1
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+The windows build seems to be hardcoded to finding git at c:\program files\Git\
+I have git in another directory. Git-annex does not find it.
+
+### What steps will reproduce the problem?
+
+Install git-annex. Run the webapp.
+Get error "Internal Server Error 
+You need to install git in order to use git-annex!"
+
+### What version of git-annex are you using? On what operating system?
+
+Latest windows build, from 20140817
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

Added a comment: Log with --debug
diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment
new file mode 100644
index 0000000..6f5570e
--- /dev/null
+++ b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jg123h12jh3y12g3y"
+ ip="86.62.100.131"
+ subject="Log with --debug"
+ date="2014-08-20T05:49:02Z"
+ content="""
+https://mega.co.nz/#!HYZmwSIb!gCd9jvVIyYye_bpsUq_vuEed4g7NTlEl2xDRheE1Lx4
+
+This is the log of git annex repair --debug.
+"""]]

Added a comment: brew doesn't include git-remote-gcrypt
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
new file mode 100644
index 0000000..99f3b7c
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="46.14.43.36"
+ subject="brew doesn't include git-remote-gcrypt"
+ date="2014-08-19T21:54:16Z"
+ content="""
+Brew doesn't include git-remote-gcrypt, so I installed your fork of it manually. That works well and if you use a symlink to include it in the PATH you can easily update (pull) the repo. If one can install git-remote-gcrypt using brew, I don't know how.
+
+Best, Jean-Louis
+"""]]

clarify that --all doesn't operate on a single file
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 06e8794..11e086a 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -78,10 +78,11 @@ subdirectories).
   or transferring them from some kind of key-value store.
 
   Normally git-annex will choose which repository to copy the content from,
-  but you can override this using the `--from` option.  Only the last version
-  of the file is retrieved (use `--all` to retrieve all versions of
-  the file).  `--key=KEY` option can be used to retrieve a specified key
-  without the filename.
+  but you can override this using the `--from` option.
+ 
+  Rather than specifying a filename, the `--all` option can be used to 
+  get all available versions of all files, or the --key=KEY`
+  option can be used to get a specified key.
 
 * `drop [path ...]`
 

Added a comment: git annex view */=podcast
diff --git a/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
new file mode 100644
index 0000000..e522ed8
--- /dev/null
+++ b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="git annex view */=podcast"
+ date="2014-08-19T06:11:50Z"
+ content="""
+Hi,
+
+Would it be hard to handle the wildcard character in the location view before the = sign.
+
+    git annex foo/=*
+
+works but
+
+    git annex *=/bar
+
+does not.
+"""]]

doc/ minor typos/trailing whitespaces + extension on get options
diff --git a/doc/encryption.mdwn b/doc/encryption.mdwn
index 0dac527..3cbc37e 100644
--- a/doc/encryption.mdwn
+++ b/doc/encryption.mdwn
@@ -17,7 +17,7 @@ remote.
 You should decide whether to use encryption with a special remote before
 any data is stored in it. So, `git annex initremote` requires you
 to specify "encryption=none" when first setting up a remote in order
-to disable encryption. To use encryption, you run 
+to disable encryption. To use encryption, you run
 `git-annex initremote` in one of these ways:
 
 * `git annex initremote newremote type=... encryption=hybrid keyid=KEYID ...`
@@ -29,10 +29,10 @@ to disable encryption. To use encryption, you run
 The [[hybrid_key_design|design/encryption]] allows additional
 encryption keys to be added on to a special remote later. Due to this
 flexibility, it is the default and recommended encryption scheme.
- 
+
 	git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID ...
 
-Here the KEYID(s) are passed to `gpg` to find encryption keys. 
+Here the KEYID(s) are passed to `gpg` to find encryption keys.
 Typically, you will say "keyid=2512E3C7" to use a specific gpg key.
 Or, you might say "keyid=joey@kitenet.net" to search for matching keys.
 
@@ -58,8 +58,8 @@ risks associated with encryption.
 Alternatively, you can configure git-annex to use a shared cipher to
 encrypt data stored in a remote. This shared cipher is stored,
 **unencrypted** in the git repository. So it's shared among every
-clone of the git repository. 
-	
+clone of the git repository.
+
 	git annex initremote newremote type=... encryption=shared
 
 The advantage is you don't need to set up gpg keys. The disadvantage is
@@ -74,10 +74,10 @@ and since it's exactly the way everyone else uses gpg.
 
 	git annex initremote newremote type=.... encryption=pubkey keyid=KEYID ...
 
-A disavantage is that it is not easy to later add additional public keys
+A disadvantage is that it is not easy to later add additional public keys
 to the special remote. While the `enableremote` parameters `keyid+=` and
 `keyid-=` can be used, they have **no effect** on files that are already
-present on the remote. Probably the only use for these parameters is 
+present on the remote. Probably the only use for these parameters is
 to replace a revoked key:
 
 	git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 673e86f..06e8794 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -64,7 +64,7 @@ subdirectories).
 
   Adds files in the path to the annex. If no path is specified, adds
   files from the current directory and below.
-  
+
   Files that are already checked into git, or that git has been configured
   to ignore will be silently skipped. (Use `--force` to add ignored files.)
 
@@ -78,7 +78,10 @@ subdirectories).
   or transferring them from some kind of key-value store.
 
   Normally git-annex will choose which repository to copy the content from,
-  but you can override this using the `--from` option.
+  but you can override this using the `--from` option.  Only the last version
+  of the file is retrieved (use `--all` to retrieve all versions of
+  the file).  `--key=KEY` option can be used to retrieve a specified key
+  without the filename.
 
 * `drop [path ...]`
 
@@ -272,10 +275,10 @@ subdirectories).
   (Other available variables: feedauthor, itemauthor, itemsummary, itemdescription, itemrights, itemid, itempubdate, title, author)
 
   The `--relaxed` and `--fast` options behave the same as they do in addurl.
-  
+
   When quvi is installed, links in the feed are tested to see if they
   are on a video hosting site, and the video is downloaded. This allows
-  importing eg, youtube playlists.
+  importing e.g., youtube playlists.
 
 * `watch`
 
@@ -319,7 +322,7 @@ subdirectories).
   This disables running a local web browser, and outputs the url you
   can use to open the webapp.
 
-  When using the webapp on a remote computer, you'll almost certianly
+  When using the webapp on a remote computer, you'll almost certainly
   want to enable HTTPS. The webapp will use HTTPS if it finds
   a .git/annex/privkey.pem and .git/annex/certificate.pem. Here's
   one way to generate those files, using a self-signed certificate:
@@ -388,7 +391,7 @@ subdirectories).
 
   The name of the remote is the same name used when originally
   creating that remote with "initremote". Run "git annex enableremote"
-  with no parameters to get a list of special remote names.
+  without any name to get a list of special remote names.
 
   Some special remotes may need parameters to be specified every time.
   For example, the directory special remote requires a directory= parameter.
@@ -425,7 +428,7 @@ subdirectories).
   Run without a number to get the current value.
 
   When git-annex is asked to drop a file, it first verifies that the
-  required number of copies can be satisfied amoung all the other
+  required number of copies can be satisfied among all the other
   repositories that have a copy of the file.
 
   This can be overridden on a per-file basis by the annex.numcopies setting
@@ -645,7 +648,7 @@ subdirectories).
   `--format`. The default output format is the same as `--format='${file}\\n'`
 
   These variables are available for use in formats: file, key, backend,
-  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for 
+  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for
   the mtime field of a WORM key).
 
 * `whereis [path ...]`
@@ -715,13 +718,13 @@ subdirectories).
 
 * `metadata [path ...] [-s field=value -s field+=value -s field-=value ...] [-g field]`
 
-  The content of a file can have any number of metadata fields 
+  The content of a file can have any number of metadata fields
   attached to it to describe it. Each metadata field can in turn
-  have any number of values. 
-  
+  have any number of values.
+
   This command can be used to set metadata, or show the currently set
   metadata.
-  
+
   To show current metadata, run without any -s parameters. The --json
   option will enable json output.
 
@@ -750,7 +753,7 @@ subdirectories).
   and checks out the view branch. Only files in the current branch whose
   metadata matches all the specified field values and tags will be
   shown in the view.
-  
+
   Multiple values for a metadata field can be specified, either by using
   a glob (`field="*"`) or by listing each wanted value. The resulting view
   will put files in subdirectories according to the value of their fields.
@@ -785,9 +788,9 @@ subdirectories).
   Changes the current view, adding an additional level of directories
   to categorize the files.
 
-  For example, when the view is by author/tag, `vadd year=*` will 
-  change it to year/author/tag. 
-  
+  For example, when the view is by author/tag, `vadd year=*` will
+  change it to year/author/tag.
+
   So will `vadd year=2014 year=2013`, but limiting the years in view
   to only those two.
 
@@ -934,7 +937,7 @@ subdirectories).
 * `findref [ref]`
 
   This is similar to the find command, but instead of finding files in the
-  current work tree, it finds files in the specified git ref. 
+  current work tree, it finds files in the specified git ref.
 
   Most MATCHING OPTIONS can be used with findref, to limit the files it
   finds. However, the --include and --exclude options will not work.
@@ -1125,7 +1128,7 @@ subdirectories).
   Caused a desktop notification to be displayed after each successful
   file download and upload.
 
-  (Only supported on some platforms, eg Linux with dbus. A no-op when
+  (Only supported on some platforms, e.g. Linux with dbus. A no-op when
   not supported.)
 
 * `--notify-start`
@@ -1316,7 +1319,7 @@ to e.g., fsck a repository on a removable drive when the drive gets
 connected.
 
 The scheduled jobs can be configured using `git annex vicfg` or
-`git annex schedule`. 
+`git annex schedule`.
 
 These actions are available: "fsck self", "fsck UUID" (where UUID
 is the UUID of a remote to fsck). After the action comes the duration
@@ -1372,7 +1375,7 @@ Here are all the supported configuration settings.
 
   This is a deprecated setting. You should instead use the
   `git annex numcopies` command to configure how many copies of files
-  are kept acros all repositories.
+  are kept across all repositories.
 
   This config setting is only looked at when `git annex numcopies` has
   never been configured.

(Diff truncated)
diff --git a/doc/forum/adding_files_without_hashing_them.mdwn b/doc/forum/adding_files_without_hashing_them.mdwn
new file mode 100644
index 0000000..a9aef30
--- /dev/null
+++ b/doc/forum/adding_files_without_hashing_them.mdwn
@@ -0,0 +1 @@
+I would like to be able to add files without having to hash its contents (like WORM) but being able to modify them and record its changes. Is this possible? In other words, I would like to provide other not-that-expensive mechanism for identifying files of a particular version.

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment
new file mode 100644
index 0000000..72bc4f8
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 5"
+ date="2014-08-18T20:54:10Z"
+ content="""
+> True of a single filesystem, but not of a set of connected git repositories.
+
+That’s a good point. Might depend on the use case, though.
+
+> The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place. 
+
+This one I’m not completely sure about. E.g., I have an annex with web pages mirrored from the web. Due to the crawler implementation, there are lots of «index.html» or «favicon.ico» with the same mtime (in particular when mtime is read with a 1 sec. precision). Files like favicon are often bitmaps of the same resolution and often have the same size due to this. Because there are file-formats where both size and basename are semantically pre-determined, there is zero entropy from these sources alone (also cf. «readme.txt»). The entropy of mtime alone is not really large, I suppose, and in some use-cases will also approach zero (think «initializing a repo by cp -r on a fast disk without preserving mtime). The relative path could make a huge difference there. I believe this argument is actually what worried me the most. Does it seem valid?
+
+Apart from entropy, there’s the non-probabilistic advantage we discussed (granted, with some limiting constraints which one has to assure for oneself). Granted, one might argue a hash would be the better way, but this is not always practical in every setup.
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment
new file mode 100644
index 0000000..a02b1de
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 4"
+ date="2014-08-18T18:39:33Z"
+ content="""
+> Rather than saying that the relative path adds additional entropy, what I was aiming at is the file-system cannot have two alternate versions of one file name at the same path with the same mtime
+
+True of a single filesystem, but not of a set of connected git repositories. :)
+
+So there are multiple scenarios when encoding the file path in the key doesn't help. The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place. It's not clear to me that it adds more than a false sense of security to change from basename to git filename.
+"""]]

cleanup branch list
diff --git a/doc/download.mdwn b/doc/download.mdwn
index 8c6f5b5..46d397f 100644
--- a/doc/download.mdwn
+++ b/doc/download.mdwn
@@ -26,13 +26,10 @@ The git repository has some branches:
   (merge it into master if you need it)
 * `no-bloom` avoids using bloom filters. (merge it into master if you need it)
 * `no-s3` avoids using the S3 library (merge it into master if you need it)
-* `debian-stable` contains the latest backport of git-annex to Debian
-  stable.
+* `debian-*-backport` contains the latest backport of git-annex.
 * `tweak-fetch` adds support for the git tweak-fetch hook, which has
   been proposed and implemented but not yet accepted into git.
 * `setup` contains configuration for this website
-* `pristine-tar` contains [pristine-tar](http://kitenet.net/~joey/code/pristine-tar)
-  data to create tarballs of any past git-annex release.
 
 ----
 

add news item for git-annex 5.20140817
diff --git a/doc/news/version_5.20140606.mdwn b/doc/news/version_5.20140606.mdwn
deleted file mode 100644
index d7f26b8..0000000
--- a/doc/news/version_5.20140606.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-git-annex 5.20140606 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * webapp: When adding a new local repository, fix bug that caused its
-     group and preferred content to be set in the current repository,
-     even when not combining.
-   * webapp: Avoid stomping on existing description, group and
-     preferred content settings when enabling or combining with
-     an already existing remote.
-   * assistant: Make sanity checker tmp dir cleanup code more robust.
-   * unused: Avoid checking view branches for unused files.
-   * webapp: Include ssh port in mangled hostname.
-   * Windows: Fix bug introduced in last release that caused files
-     in the git-annex branch to have lines teminated with \r.
-   * Windows: Fix retrieving of files from local bare git repositories."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140817.mdwn b/doc/news/version_5.20140817.mdwn
new file mode 100644
index 0000000..82e44eb
--- /dev/null
+++ b/doc/news/version_5.20140817.mdwn
@@ -0,0 +1,42 @@
+git-annex 5.20140817 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * New chunk= option to chunk files stored in special remotes.
+     Supported by: directory, S3, webdav, gcrypt, rsync, and all external
+     and hook special remotes.
+   * Partially transferred files are automatically resumed when using
+     chunked remotes!
+   * The old chunksize= option is deprecated. Do not use for new remotes.
+   * Legacy code for directory remotes using the old chunksize= option
+     will keep them working, but more slowly than before.
+   * webapp: Automatically install Konqueror integration scripts
+     to get and drop files.
+   * repair: Removing bad objects could leave fsck finding no more
+     unreachable objects, but some branches no longer accessible.
+     Fix this, including support for fixing up repositories that
+     were incompletely repaired before.
+   * Fix cost calculation for non-encrypted remotes.
+   * Display exception message when a transfer fails due to an exception.
+   * WebDAV: Sped up by avoiding making multiple http connections
+     when storing a file.
+   * WebDAV: Avoid buffering whole file in memory when uploading and
+     downloading.
+   * WebDAV: Dropped support for DAV before 1.0.
+   * testremote: New command to test uploads/downloads to a remote.
+   * Dropping an object from a bup special remote now deletes the git branch
+     for the object, although of course the object's content cannot be deleted
+     due to the nature of bup.
+   * unlock: Better error handling; continue past files that are not available
+     or cannot be unlocked due to disk space, and try all specified files.
+   * Windows: Now uses actual inode equivilants in new direct mode
+     repositories, for safer detection of eg, renaming of files with the same
+     size and mtime.
+   * direct: Fix ugly warning messages.
+   * WORM backend: When adding a file in a subdirectory, avoid including the
+     subdirectory in the key name.
+   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
+     when the repository was configured with encryption=shared embedcreds=yes.
+   * direct: Avoid leaving file content in misctemp if interrupted.
+   * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
+     that already has a transfer lock file indicating it's being sent to that
+     remote. The remote may have moved between networks, or reconnected.
+   * Switched from the old haskell HTTP library to http-conduit."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
new file mode 100644
index 0000000..4b3f024
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 3"
+ date="2014-08-16T15:22:35Z"
+ content="""
+Ah, well then, that sounds a lot more reasonable. Though legal, I have yet to hear of a sane reason for using newlines in filenames.
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment
new file mode 100644
index 0000000..54fe869
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 3"
+ date="2014-08-16T13:58:28Z"
+ content="""
+One scenario where the above guarantee would be violated is when one
+moves a new file of identical size, basename, and mtime, into a path
+where a key-colliding file has been kept before. Still, I’d consider
+this a scenario one could reasonably control for (especially in the
+archive usecase); plus, even without manual control such a
+move-induced collision would be much more unlikely than a collision of
+basenames only.
+
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment
new file mode 100644
index 0000000..90684d9
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 2"
+ date="2014-08-16T11:42:22Z"
+ content="""
+Hm, I don’t quite follow the remark on having everything in a single
+directory. Rather than saying that the relative path adds additional
+entropy, what I was aiming at is the file-system cannot have two
+alternate versions of one file name at the same path with the same
+mtime, and that’s why it occurred to me that encoding both path and
+mtime within the key doesn’t just increase the odds, but effectively
+_guarantees_ that there won’t be any collisions. Does this seem to
+hold up, or am I missing something? (Of course one can fudge the
+mtimes, but that’s something under the user’s control.)
+
+While a large repo with many files very likely has lots of distinct
+files with identical basename, mtime (in s.) and size, all these files
+with the same mtime must necessarily be located at different paths.
+
+"""]]

devblog
diff --git a/doc/devblog/day_217__autobuilders.mdwn b/doc/devblog/day_217__autobuilders.mdwn
new file mode 100644
index 0000000..2a58e0c
--- /dev/null
+++ b/doc/devblog/day_217__autobuilders.mdwn
@@ -0,0 +1,10 @@
+Over the past couple days, got the arm autobuilder working again. It had
+been down since June with several problems. cabal install tended to crash;
+apparenty this has something to do with threading in user-mode qemu,
+because -j1 avoids that. And strange invalid character problems were fixed
+by downgrading file-embed. Also, with Yury's help I got the Windows
+autobuilder upgraded to the new Haskell Platform and working again.
+
+Today a last few finishing touches, including getting rid of the last
+dependency on the old haskell HTTP library, since http-conduit is being
+used now. Ready for the release!

Added a comment
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
new file mode 100644
index 0000000..e80d66b
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 4"
+ date="2014-08-15T20:51:12Z"
+ content="""
+Bonus question: is there any way to bring this repo back into a working state (for instance with git-filter-branch?) ?
+"""]]

Added a comment
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
new file mode 100644
index 0000000..8651405
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 3"
+ date="2014-08-15T20:45:38Z"
+ content="""
+I've been experiencing the exact same problem and searching for **recovery from race** lead me to this bug report. Thanks for reporting it!
+
+For a few months, a repo storing ~19'000 files (mostly immutable pictures) started to launch memory hungry \"git log\" processes. For example:
+
+    4797 francois  20   0 8118296 7.719g   2032 D  22.3 50.2   0:11.61 git                                                                                                   
+
+    4797 pts/1    D+     0:12 git --git-dir=~/Pictures/.git --work-tree=~/Pictures -c core.bare=false log refs/heads/git-annex..52e44b967ad5d316d832562be02c5555c1f6d2a4 --oneline -n1
+
+Thanks to the hints found in this report, I was able to find many huge commit messages such as this one:
+
+    $ git show 6357b208 
+    commit 6357b2081e7c85dfe1ccc10824b75f3e212e6386
+    Author: Francois Deppierraz <francois@ctrlaltdel.ch>
+    Date:   Sat Jun 14 10:38:46 2014 +0200
+
+        update (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) [...]
+
+    $ git show 6357b208 | wc 
+      5  444026 3108236
+
+There were probably many new files added on Jun 14th and looking for a way to increase to sync speed, especially to a S3-like remote, I found the solution on this wiki for [multiple concurrent transfers](https://git-annex.branchable.com/forum/Feature_request:_Multiple_concurrent_transfers/).
+
+This looks like a likely culprit for generating race conditions. What do you think?
+
+    git-annex version: 5.20140412ubuntu1
+"""]]

silly markdown..
diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn
index 0531ddb..a9c49a9 100644
--- a/doc/devblog/day_216__various_minor_bugs.mdwn
+++ b/doc/devblog/day_216__various_minor_bugs.mdwn
@@ -1,7 +1,7 @@
 Working on getting caught up with backlog. 73 messages remain.
 
 Several minor bugs were fixed today. All edge cases. The most edge case one
-of all, I could not fix: git-annex cannot add a file that has a space^Wnewline
+of all, I could not fix: git-annex cannot add a file that has a newline
 in its filename, because `git cat-file --batch`'s interface does not support such
 filenames.
 

Added a comment
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
new file mode 100644
index 0000000..559689b
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T19:45:28Z"
+ content="""
+That was a typo. Of course, spaces are no problem. Newlines in filenames, on the other hand..
+"""]]

fix link
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 0d8bb1d..7fe21c9 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -3,7 +3,7 @@
 [[!table format=dsv header=yes data="""
 detailed instructions             | quick install
 [[OSX]]                           | [download git-annex.app](http://downloads.kitenet.net/git-annex/OSX/current/)
-&nbsp;&nbsp;[[Homebrew]]            | `brew install git-annex`
+&nbsp;&nbsp;[[OSX/Homebrew]]      | `brew install git-annex`
 [[Android]]                       | [download git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/) **beta**
 [[Linux|linux_standalone]]        | [download prebuilt linux tarball](http://downloads.kitenet.net/git-annex/linux/current/)
 &nbsp;&nbsp;[[Debian]]            | `apt-get install git-annex`

Added a comment
diff --git a/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
new file mode 100644
index 0000000..902d87d
--- /dev/null
+++ b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 8"
+ date="2014-08-15T19:26:07Z"
+ content="""
+@David, the bundle contains the man page since a while.
+
+@Michael, the best way to get a git-annex that does not use those bundled programs is probably to instead install it using homebrew.
+"""]]

more reorg
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index 775771e..0eab6eb 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -36,4 +36,4 @@ MacPorts tools. See [[MacPorts]].
 
 ## building it yourself
 
-See [[cabal]].
+See [[porting]].
diff --git a/doc/install/OSX/cabal.mdwn b/doc/install/OSX/cabal.mdwn
deleted file mode 100644
index b3629c6..0000000
--- a/doc/install/OSX/cabal.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-If you cannot get a OSX build of git-annex suitable for your computer,
-from eg [[HomeBrew]] or the regular [[OSX]] prebuilt app, you
-can try Building git-annex from source on OSX, using haskell's cabal package
-manager.
-
-For general instructions for using cabal, see [[this page|/install/cabal]].
diff --git a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
deleted file mode 100644
index d0c74d6..0000000
--- a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
- nickname="Eric"
- subject="Updating to latest build"
- date="2013-01-25T06:05:35Z"
- content="""
-What is the appropriate way to update to the latest build of git-annex using cabal?
-"""]]
diff --git a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
deleted file mode 100644
index 875db34..0000000
--- a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.154.3.125"
- subject="comment 13"
- date="2013-02-05T19:46:29Z"
- content="""
-@eric `cabal update && cabal upgrade git-annex`
-"""]]
diff --git a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
deleted file mode 100644
index 1072dbc..0000000
--- a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmCmNS-oUgYfNg85-LPuxzTZJUp0sIgprM"
- nickname="Jonas"
- subject="more homebrew"
- date="2013-02-16T19:46:47Z"
- content="""
-i had macports installed. then i installed brew, instaled haskell via brew. i needed to set 
-    PATH=$HOME/bin:/usr/local/bin:$PATH
-"""]]
diff --git a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
deleted file mode 100644
index 05f5654..0000000
--- a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="https://launchpad.net/~wincus"
- nickname="Juan Moyano"
- subject="git annex on Snow Leopard"
- date="2013-03-26T16:02:54Z"
- content="""
-I'm having the same issue as @Pere, with a newer version of DAV :(
-
-cabal: Error: some packages failed to install:
-DAV-0.3.1 failed during the building phase. The exception was:
-ExitFailure 11
-git-annex-4.20130323 depends on shakespeare-css-1.0.3 which failed to install.
-persistent-1.1.5.1 failed during the building phase. The exception was:
-ExitFailure 11
-persistent-template-1.1.3.1 depends on persistent-1.1.5.1 which failed to
-install.
-shakespeare-css-1.0.3 failed during the building phase. The exception was:
-ExitFailure 11
-yesod-1.1.9.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-auth-1.1.5.3 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-core-1.1.8.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-default-1.1.3.2 depends on shakespeare-css-1.0.3 which failed to
-install.
-yesod-form-1.2.1.3 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-json-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-persistent-1.1.0.1 depends on shakespeare-css-1.0.3 which failed to
-install.
-yesod-static-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
-
-
-
-*Any ideas?*
-
-
-"""]]
diff --git a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
deleted file mode 100644
index 0098e74..0000000
--- a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
+++ /dev/null
@@ -1,36 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
- nickname="Bret"
- subject="Snow Leopard Issues"
- date="2013-04-14T20:17:17Z"
- content="""
-I was able to build snow leopard completely for the first time over last night (it took a very long time to build all the tools and dependancies).  Woohoo!
-
-The way I was able to fully build on a 32-bit 10.6 machine was this
-
-1. Delete ~/.ghc and ~/.cabal.  They were full of random things and were causing problems.
-2. `brew uninstall ghc and haskell-platform`
-3. `brew update`
-4. `brew install git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2`
-5. `brew upgrade git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2` (Some of these were already installed/up to date.
-6. `brew link libxml2`
-7. `brew install haskell-platform`  (This takes a long, long time).
-8. `cabal update` (assuming you have added `~/.cabal/bin` to your path
-9. `cabal install cablal-install`
-10. `cabal install c2hs`
-11. `cabal install git-annex`
-
-
-It also appears to be running fairly smoothly than it had in the past on a 32-bit SL system.  Thats also neat.  
-
-The problem is that it seems to not really work as git annex though, probably due to the error relating you get when you start up the webapp:
-Running
-`git annex webapp` 
-The browser starts up, and I get 3 of these errors:
-`Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents`
-
-Pairing with a local computer appears to work to systems running 10.7, but when you complete the process, they never show up in the repository list.
-
-
-Also on a side note, when running `git annex webapp` it triggers the opening of an html file in whatever the default html file handler is.  I edit a lot of html, so for me that is usually a text editor.  I had to change the file handler to open html files with my web browser for the `git annex webapp` to actually work.  Is there a way to change that so that `git annex webapp` uses the default web browser for the system rather than the default html file handler?
-"""]]
diff --git a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
deleted file mode 100644
index 7dfa481..0000000
--- a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
- nickname="Andrew"
- subject="comment 22"
- date="2013-07-25T02:19:53Z"
- content="""
-Rather than specifying --bindir on the command line for cabal, I edited my ~/.cabal/config to add this line:
-
-    symlink-bindir: /usr/local/bin
-
-This installs the binaries to ~/.cabal/bin but symlinks them into /usr/local/bin alongside the links that homebrew installs. Additionally, I symlinked /usr/local/bin/git-annex-shell to /usr/local/bin/git-annex which made things work great from remote hosts via ssh.
-"""]]
diff --git a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
deleted file mode 100644
index 08792aa..0000000
--- a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
- nickname="Kristian"
- subject="Build failure using Haskel Platform"
- date="2013-09-15T18:49:01Z"
- content="""
-I get this error when I try to build git-annex using \"cabal install git-annex\"
-
-    [ 34 of 347] Compiling Utility.Misc     ( Utility/Misc.hs, dist/build/git-annex/git-annex-tmp/Utility/Misc.o )
-    [ 35 of 347] Compiling Utility.Process  ( Utility/Process.hs, dist/build/git-annex/git-annex-tmp/Utility/Process.o )
-    [ 36 of 347] Compiling Utility.Network  ( Utility/Network.hs, dist/build/git-annex/git-annex-tmp/Utility/Network.o )
-    [ 37 of 347] Compiling Utility.SRV      ( Utility/SRV.hs, dist/build/git-annex/git-annex-tmp/Utility/SRV.o )
-    
-    Utility/SRV.hs:70:54:
-        Couldn't match expected type `Maybe
-                                        [(Int, Int, Integer, B8.ByteString)]'
-                    with actual type `Either
-                                        dns-1.0.0:Network.DNS.Internal.DNSError
-                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
-        In the third argument of `maybe', namely `r'
-        In the second argument of `($)', namely
-          `maybe [] (orderHosts . map tohosts) r'
-        In a stmt of a 'do' block:
-          return $ maybe [] (orderHosts . map tohosts) r
-    Failed to install git-annex-4.20130909
-    cabal: Error: some packages failed to install:
-    git-annex-4.20130909 failed during the building phase. The exception was:
-    ExitFailure 1

(Diff truncated)
move cabal on OSX stuff to its own page
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index edfeff6..775771e 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -32,4 +32,8 @@ git-annex is now [[available in Homebrew|Homebrew]]!
 ## using MacPorts
 
 git-annex is not available in MacPorts, but can be built from source using
-MacPorts tools. See [[MacPorts]]
+MacPorts tools. See [[MacPorts]].
+
+## building it yourself
+
+See [[cabal]].
diff --git a/doc/install/OSX/cabal.mdwn b/doc/install/OSX/cabal.mdwn
new file mode 100644
index 0000000..b3629c6
--- /dev/null
+++ b/doc/install/OSX/cabal.mdwn
@@ -0,0 +1,6 @@
+If you cannot get a OSX build of git-annex suitable for your computer,
+from eg [[HomeBrew]] or the regular [[OSX]] prebuilt app, you
+can try Building git-annex from source on OSX, using haskell's cabal package
+manager.
+
+For general instructions for using cabal, see [[this page|/install/cabal]].
diff --git a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
new file mode 100644
index 0000000..d0c74d6
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
+ nickname="Eric"
+ subject="Updating to latest build"
+ date="2013-01-25T06:05:35Z"
+ content="""
+What is the appropriate way to update to the latest build of git-annex using cabal?
+"""]]
diff --git a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
new file mode 100644
index 0000000..875db34
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 13"
+ date="2013-02-05T19:46:29Z"
+ content="""
+@eric `cabal update && cabal upgrade git-annex`
+"""]]
diff --git a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
new file mode 100644
index 0000000..1072dbc
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmCmNS-oUgYfNg85-LPuxzTZJUp0sIgprM"
+ nickname="Jonas"
+ subject="more homebrew"
+ date="2013-02-16T19:46:47Z"
+ content="""
+i had macports installed. then i installed brew, instaled haskell via brew. i needed to set 
+    PATH=$HOME/bin:/usr/local/bin:$PATH
+"""]]
diff --git a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
new file mode 100644
index 0000000..05f5654
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~wincus"
+ nickname="Juan Moyano"
+ subject="git annex on Snow Leopard"
+ date="2013-03-26T16:02:54Z"
+ content="""
+I'm having the same issue as @Pere, with a newer version of DAV :(
+
+cabal: Error: some packages failed to install:
+DAV-0.3.1 failed during the building phase. The exception was:
+ExitFailure 11
+git-annex-4.20130323 depends on shakespeare-css-1.0.3 which failed to install.
+persistent-1.1.5.1 failed during the building phase. The exception was:
+ExitFailure 11
+persistent-template-1.1.3.1 depends on persistent-1.1.5.1 which failed to
+install.
+shakespeare-css-1.0.3 failed during the building phase. The exception was:
+ExitFailure 11
+yesod-1.1.9.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-auth-1.1.5.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-core-1.1.8.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-default-1.1.3.2 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-form-1.2.1.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-json-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-persistent-1.1.0.1 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-static-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+
+
+
+*Any ideas?*
+
+
+"""]]
diff --git a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
new file mode 100644
index 0000000..0098e74
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Snow Leopard Issues"
+ date="2013-04-14T20:17:17Z"
+ content="""
+I was able to build snow leopard completely for the first time over last night (it took a very long time to build all the tools and dependancies).  Woohoo!
+
+The way I was able to fully build on a 32-bit 10.6 machine was this
+
+1. Delete ~/.ghc and ~/.cabal.  They were full of random things and were causing problems.
+2. `brew uninstall ghc and haskell-platform`
+3. `brew update`
+4. `brew install git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2`
+5. `brew upgrade git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2` (Some of these were already installed/up to date.
+6. `brew link libxml2`
+7. `brew install haskell-platform`  (This takes a long, long time).
+8. `cabal update` (assuming you have added `~/.cabal/bin` to your path
+9. `cabal install cablal-install`
+10. `cabal install c2hs`
+11. `cabal install git-annex`
+
+
+It also appears to be running fairly smoothly than it had in the past on a 32-bit SL system.  Thats also neat.  
+
+The problem is that it seems to not really work as git annex though, probably due to the error relating you get when you start up the webapp:
+Running
+`git annex webapp` 
+The browser starts up, and I get 3 of these errors:
+`Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents`
+
+Pairing with a local computer appears to work to systems running 10.7, but when you complete the process, they never show up in the repository list.
+
+
+Also on a side note, when running `git annex webapp` it triggers the opening of an html file in whatever the default html file handler is.  I edit a lot of html, so for me that is usually a text editor.  I had to change the file handler to open html files with my web browser for the `git annex webapp` to actually work.  Is there a way to change that so that `git annex webapp` uses the default web browser for the system rather than the default html file handler?
+"""]]
diff --git a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
new file mode 100644
index 0000000..7dfa481
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 22"
+ date="2013-07-25T02:19:53Z"
+ content="""
+Rather than specifying --bindir on the command line for cabal, I edited my ~/.cabal/config to add this line:
+
+    symlink-bindir: /usr/local/bin
+
+This installs the binaries to ~/.cabal/bin but symlinks them into /usr/local/bin alongside the links that homebrew installs. Additionally, I symlinked /usr/local/bin/git-annex-shell to /usr/local/bin/git-annex which made things work great from remote hosts via ssh.
+"""]]
diff --git a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
new file mode 100644
index 0000000..08792aa
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
+ nickname="Kristian"
+ subject="Build failure using Haskel Platform"
+ date="2013-09-15T18:49:01Z"
+ content="""
+I get this error when I try to build git-annex using \"cabal install git-annex\"
+
+    [ 34 of 347] Compiling Utility.Misc     ( Utility/Misc.hs, dist/build/git-annex/git-annex-tmp/Utility/Misc.o )
+    [ 35 of 347] Compiling Utility.Process  ( Utility/Process.hs, dist/build/git-annex/git-annex-tmp/Utility/Process.o )
+    [ 36 of 347] Compiling Utility.Network  ( Utility/Network.hs, dist/build/git-annex/git-annex-tmp/Utility/Network.o )
+    [ 37 of 347] Compiling Utility.SRV      ( Utility/SRV.hs, dist/build/git-annex/git-annex-tmp/Utility/SRV.o )
+    
+    Utility/SRV.hs:70:54:
+        Couldn't match expected type `Maybe
+                                        [(Int, Int, Integer, B8.ByteString)]'
+                    with actual type `Either
+                                        dns-1.0.0:Network.DNS.Internal.DNSError
+                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
+        In the third argument of `maybe', namely `r'
+        In the second argument of `($)', namely
+          `maybe [] (orderHosts . map tohosts) r'
+        In a stmt of a 'do' block:
+          return $ maybe [] (orderHosts . map tohosts) r

(Diff truncated)
reorg, moving MacPorts to a separate page
diff --git a/doc/install/Homebrew.mdwn b/doc/install/Homebrew.mdwn
deleted file mode 100644
index bd9a840..0000000
--- a/doc/install/Homebrew.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[Homebrew](http://brew.sh/) has [a formula](https://github.com/Homebrew/homebrew/commits/master/Library/Formula/git-annex.rb) for git-annex.
-
-Homebrew users can simply run `brew install git-annex` to install git-annex.
-
-## buiding git-annex from sources
-
-This is the old recipe for building git-annex from source, using
-packages from homebrew. Useful if you want a newer version than the version
-in homebrew.
-
-<pre>
-brew install haskell-platform git ossp-uuid md5sha1sum coreutils gnutls libidn gsasl pkg-config libxml2
-brew link libxml2 --force
-cabal update
-mkdir $HOME/bin
-PATH=$HOME/bin:$PATH
-PATH=$HOME/.cabal/bin:$PATH
-cabal install c2hs --bindir=$HOME/bin
-cabal install gnuidn
-cabal install git-annex --bindir=$HOME/bin
-</pre>
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index 5a1505c..edfeff6 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -31,25 +31,5 @@ git-annex is now [[available in Homebrew|Homebrew]]!
 
 ## using MacPorts
 
-Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]].
-The version provided by Macports is too old to work with current versions of git-annex.
-Then execute
-
-<pre>
-sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig
-sudo cabal update
-PATH=$HOME/bin:$PATH
-cabal install c2hs git-annex --bindir=$HOME/bin
-</pre>
-
-## PATH setup
-
-Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example:
-<pre>
-PATH=$HOME/bin:$PATH
-</pre>
-
-See also:
-
-* [[forum/OSX__39__s_haskell-platform_statically_links_things]]
-* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]]
+git-annex is not available in MacPorts, but can be built from source using
+MacPorts tools. See [[MacPorts]]
diff --git a/doc/install/OSX/Homebrew.mdwn b/doc/install/OSX/Homebrew.mdwn
new file mode 100644
index 0000000..bd9a840
--- /dev/null
+++ b/doc/install/OSX/Homebrew.mdwn
@@ -0,0 +1,21 @@
+[Homebrew](http://brew.sh/) has [a formula](https://github.com/Homebrew/homebrew/commits/master/Library/Formula/git-annex.rb) for git-annex.
+
+Homebrew users can simply run `brew install git-annex` to install git-annex.
+
+## buiding git-annex from sources
+
+This is the old recipe for building git-annex from source, using
+packages from homebrew. Useful if you want a newer version than the version
+in homebrew.
+
+<pre>
+brew install haskell-platform git ossp-uuid md5sha1sum coreutils gnutls libidn gsasl pkg-config libxml2
+brew link libxml2 --force
+cabal update
+mkdir $HOME/bin
+PATH=$HOME/bin:$PATH
+PATH=$HOME/.cabal/bin:$PATH
+cabal install c2hs --bindir=$HOME/bin
+cabal install gnuidn
+cabal install git-annex --bindir=$HOME/bin
+</pre>
diff --git a/doc/install/OSX/MacPorts.mdwn b/doc/install/OSX/MacPorts.mdwn
new file mode 100644
index 0000000..379e42d
--- /dev/null
+++ b/doc/install/OSX/MacPorts.mdwn
@@ -0,0 +1,27 @@
+This is not a recommended way to install git-annex. Use [[HomeBrew]] or the
+prebuilt app bundle instead.
+
+But if you really want to use MacPorts:
+
+Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]].
+The version provided by Macports is too old to work with current versions of git-annex.
+Then execute
+
+<pre>
+sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig
+sudo cabal update
+PATH=$HOME/bin:$PATH
+cabal install c2hs git-annex --bindir=$HOME/bin
+</pre>
+
+## PATH setup
+
+Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example:
+<pre>
+PATH=$HOME/bin:$PATH
+</pre>
+
+See also:
+
+* [[forum/OSX__39__s_haskell-platform_statically_links_things]]
+* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]]
diff --git a/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
new file mode 100644
index 0000000..e7d42b5
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJdzisfT6DhorwRz0kKJ_9-zQbccCopu4"
+ nickname="Alejandro"
+ subject="Macports _iconv"
+ date="2013-07-18T14:23:02Z"
+ content="""
+If you get an error like `undefined symbol _iconv for x86_64`, you're most likely using libiconv installed by macports. You can fix this by running
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+"""]]
diff --git a/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
new file mode 100644
index 0000000..69f3f0f
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
+ nickname="Daniel"
+ subject="comment 3"
+ date="2013-01-15T15:22:43Z"
+ content="""
+Installing via the MacPorts method. I ran into this error.
+
+    \"_locale_charset\", referenced from: _localeEncoding in libHSbase-4.5.1.0.a(PrelIOUtils.o) 
+    ld: symbol(s) not found for architecture x86_64
+
+I was able to solve and get git-annex to build buy providing the --extra-lib-dirs parameter
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+Cheers, [Daniel Wozniak](http://woz.io)
+"""]]
diff --git a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment
deleted file mode 100644
index e7d42b5..0000000
--- a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmJdzisfT6DhorwRz0kKJ_9-zQbccCopu4"
- nickname="Alejandro"
- subject="Macports _iconv"
- date="2013-07-18T14:23:02Z"
- content="""
-If you get an error like `undefined symbol _iconv for x86_64`, you're most likely using libiconv installed by macports. You can fix this by running
-
-    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
-
-"""]]
diff --git a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
deleted file mode 100644
index 69f3f0f..0000000
--- a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
- nickname="Daniel"
- subject="comment 3"
- date="2013-01-15T15:22:43Z"
- content="""
-Installing via the MacPorts method. I ran into this error.
-
-    \"_locale_charset\", referenced from: _localeEncoding in libHSbase-4.5.1.0.a(PrelIOUtils.o) 
-    ld: symbol(s) not found for architecture x86_64
-
-I was able to solve and get git-annex to build buy providing the --extra-lib-dirs parameter
-
-    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
-
-Cheers, [Daniel Wozniak](http://woz.io)
-"""]]

close
diff --git a/doc/bugs/Truncated_file_transferred_via_S3.mdwn b/doc/bugs/Truncated_file_transferred_via_S3.mdwn
index 9261c8a..b489f60 100644
--- a/doc/bugs/Truncated_file_transferred_via_S3.mdwn
+++ b/doc/bugs/Truncated_file_transferred_via_S3.mdwn
@@ -612,3 +612,6 @@ BST] XMPPClient: NetMessager stored Pushing "e57" (ReceivePackDone ExitSuccess)
 
 # End of transcript or log.
 """]]
+
+> Pretty sure this must have been due to Char8 truncation. So,
+> [[fixed|done]].

git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent that already has a transfer lock file indicating it's being sent to that remote. The remote may have moved between networks, or reconnected.
diff --git a/Annex/Transfer.hs b/Annex/Transfer.hs
index ebc8e8b..5e98a87 100644
--- a/Annex/Transfer.hs
+++ b/Annex/Transfer.hs
@@ -12,6 +12,7 @@ module Annex.Transfer (
 	upload,
 	download,
 	runTransfer,
+	alwaysRunTransfer,
 	noRetry,
 	forwardRetry,
 ) where
@@ -46,12 +47,23 @@ download u key f d a _witness = runTransfer (Transfer Download u key) f d a
  - no transfer information or lock file is used.
  -}
 runTransfer :: Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
-runTransfer t file shouldretry a = do
+runTransfer = runTransfer' False
+
+{- Like runTransfer, but ignores any existing transfer lock file for the
+ - transfer, allowing re-running a transfer that is already in progress.
+ -
+ - Note that this may result in confusing progress meter display in the
+ - webapp, if multiple processes are writing to the transfer info file. -}
+alwaysRunTransfer :: Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
+alwaysRunTransfer = runTransfer' True
+
+runTransfer' :: Bool -> Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
+runTransfer' ignorelock t file shouldretry a = do
 	info <- liftIO $ startTransferInfo file
 	(meter, tfile, metervar) <- mkProgressUpdater t info
 	mode <- annexFileMode
 	(fd, inprogress) <- liftIO $ prep tfile mode info
-	if inprogress
+	if inprogress && not ignorelock
 		then do
 			showNote "transfer already in progress"
 			return False
diff --git a/Command/SendKey.hs b/Command/SendKey.hs
index a201d1b..6b5127a 100644
--- a/Command/SendKey.hs
+++ b/Command/SendKey.hs
@@ -47,3 +47,11 @@ fieldTransfer direction key a = do
 		(\u -> runTransfer (Transfer direction (toUUID u) key) afile noRetry a)
 		=<< Fields.getField Fields.remoteUUID
 	liftIO $ exitBool ok
+  where
+	{- Allow the key to be sent to the remote even if there seems to be
+	 - another transfer of that key going on to that remote.
+	 - That one may be stale, etc.
+	 -}
+	runner
+		| direction == Upload = alwaysRunTransfer
+		| otherwise = runTransfer
diff --git a/debian/changelog b/debian/changelog
index eaa36b3..c55fbab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -36,6 +36,9 @@ git-annex (5.20140718) UNRELEASED; urgency=medium
   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
     when the repository was configured with encryption=shared embedcreds=yes.
   * direct: Avoid leaving file content in misctemp if interrupted.
+  * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
+    that already has a transfer lock file indicating it's being sent to that
+    remote. The remote may have moved between networks, or reconnected.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
 
diff --git a/doc/bugs/protocol_mismatch_after_interrupt.mdwn b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
index 837690e..c2c1590 100644
--- a/doc/bugs/protocol_mismatch_after_interrupt.mdwn
+++ b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
@@ -29,3 +29,5 @@ git-annex: copy: 1 failed
 workaround: `cd .git/annex/; mv transfer transfer.old` on the other side.
 
 -- [[anarcat]]
+
+> [[fixed|done]] --[[Joey]]

Added a comment
diff --git a/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment
new file mode 100644
index 0000000..742109c
--- /dev/null
+++ b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 3"
+ date="2014-08-15T18:02:12Z"
+ content="""
+Right .. Normally it makes sense to prevent redundant transfers, but this is not the case when git-annex-shell sendkey is sending a file to a remote. Especially since the rsync protocol does not transport stderr output over the link to display to the user.
+
+Should be an easy fix.
+"""]]