Recent changes to this wiki:

Added a comment: RESOLVED / deleted all files then re-added as zip
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment
new file mode 100644
index 0000000..c8b0e33
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_6_7443fe5f7384431914c714c2b462cf5c._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="RESOLVED / deleted all files then re-added as zip"
+ date="2017-01-23T02:28:23Z"
+ content="""
+OK. I ended up having to delete all the files from git, then re-add them zipped up.
+
+I re-read the post you mentioned, this helped me resolve my issue:
+[assistant crashes in TransferScanner](http://git-annex.branchable.com/bugs/assistant_crashes_in_TransferScanner/) (from johannes)
+
+Johannes dropped the file, then re-added, that fixed his issue. So I tried that first.
+
+I did the following:
+
+ * git-annex dropped all problem files. this didn't fix issue
+ * deleted all problem files (using OS-X Finder), committed the deletion with git (git add -A), issue then fixed
+    * re-added deleted files, issue came back
+    * re-added deleted files in different folder, issue came back
+    * re-added deleted files all with different filenames in different path, issue came back
+    * zipped up folder of problem files, then added to git-annex, no issues
+
+
+"""]]

diff --git a/doc/bugs.mdwn b/doc/bugs.mdwn
index 6cb91bc..93de65e 100644
--- a/doc/bugs.mdwn
+++ b/doc/bugs.mdwn
@@ -1,4 +1,6 @@
-This is git-annex's bug list. Closed bugs are moved to [[done]].
+This is git-annex's bug list.
+
+To mark a bug as closed add \[\[done\]\] to the end of the original bug description. Closed bugs are moved to [[done]].
 
 [[!inline pages="./bugs/* and !./bugs/*/* and !./bugs/done and !link(done) 
 and !./bugs/moreinfo and !./bugs/confirmed and !./bugs/forwarded and !*/Discussion"

diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn
index a3b85bd..3dc28d4 100644
--- a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn
+++ b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn
@@ -28,3 +28,4 @@ git-annex: copy: 1 failed
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 Yes.
 
+[[done]]

formating
diff --git a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn
index 400e9bd..721bf16 100644
--- a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn
+++ b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn
@@ -2,24 +2,24 @@
 
 Opening the Android app, the following message is shown:
 
-   referenceTable GDEF length=778
-   referenceTable GSUB length=6388
-   referenceTable GPOS length=76868
+    referenceTable GDEF length=778
+    referenceTable GSUB length=6388
+    referenceTable GPOS length=76868
 
-   [Terminal session finished]
+    [Terminal session finished]
 
 I am not able to use git-annex. Trying to open a new window in git-annex, I get similar errors:
 
-   [Terminal session finished]
-   referenceTable GDEF length=778 1
-   referenceTable GSUB length=6388 1
-   referenceTable GPOS length=76868 1
-   referenceTable head length=54 1
-   referenceTable GDEF length=670
-   referenceTable GSUB length=7168
-   referenceTable GPOS length=24560
-   referenceTable head length=54 1
-   git annex webapp
+    [Terminal session finished]
+    referenceTable GDEF length=778 1
+    referenceTable GSUB length=6388 1
+    referenceTable GPOS length=76868 1
+    referenceTable head length=54 1
+    referenceTable GDEF length=670
+    referenceTable GSUB length=7168
+    referenceTable GPOS length=24560
+    referenceTable head length=54 1
+    git annex webapp
 
 
 ### What steps will reproduce the problem?

bug: Errors on Android: referenceTable GDEF length=778, referenceTable GSUB length=6388, referenceTable GPOS length=76868
diff --git a/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn
new file mode 100644
index 0000000..400e9bd
--- /dev/null
+++ b/doc/bugs/Errors_on_Android__58___referenceTable_GDEF_length__61__778__44___referenceTable_GSUB_length__61__6388__44___referenceTable_GPOS_length__61__76868.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+
+Opening the Android app, the following message is shown:
+
+   referenceTable GDEF length=778
+   referenceTable GSUB length=6388
+   referenceTable GPOS length=76868
+
+   [Terminal session finished]
+
+I am not able to use git-annex. Trying to open a new window in git-annex, I get similar errors:
+
+   [Terminal session finished]
+   referenceTable GDEF length=778 1
+   referenceTable GSUB length=6388 1
+   referenceTable GPOS length=76868 1
+   referenceTable head length=54 1
+   referenceTable GDEF length=670
+   referenceTable GSUB length=7168
+   referenceTable GPOS length=24560
+   referenceTable head length=54 1
+   git annex webapp
+
+
+### What steps will reproduce the problem?
+
+Download the most recent Android 5.0 app (I tried both [[http://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk]] and [[http://downloads.kitenet.net/git-annex/autobuild/android/5.0/git-annex.apk]]).
+Install it and open it.
+
+### What version of git-annex are you using? On what operating system?
+
+OS: Android 5.1.1.
+git-annex: I tried the currently available stable 5.0 package (6.20170101), as well as the nightly build one (it shows version 6.20170102).
+
+### 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.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, I used it successfully until recently. I remember that I installed a new version of git-annex recently. I used it successfully after the update. However, I am not sure whether I closed and reopened the git-annex app after the update.

Added a comment
diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment
new file mode 100644
index 0000000..ebebdb3
--- /dev/null
+++ b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_1_a2b90b2111bee705afa399fdb8fad23d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jesrui@51c25da8d6f34e6df8e3e7ed0277335ed7ddf6a6"
+ nickname="jesrui"
+ avatar="http://cdn.libravatar.org/avatar/079b86efcbbb1c0c54be3759a0c2b223"
+ subject="comment 1"
+ date="2017-01-21T15:08:20Z"
+ content="""
+I found the problem: I was cd'ing into the local repository via a symbolic link, instead of using the \"canonical\" path.
+You can mark the bug as solved or delete it. Sorry for the noise.
+"""]]

Added a comment: updates sync vs copy?
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment
new file mode 100644
index 0000000..17fa7b0
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_5_e96503f38cba755b2e6bd89b1ffab6ff._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="updates sync vs copy?"
+ date="2017-01-21T14:56:26Z"
+ content="""
+Any thoughts Joey? Reminder I have a v6 repo, that spits out errors `git-annex: fd:24: hFlush: resource vanished (Broken pipe)` when using sync --content.
+
+I am not sure why `git annex sync --content cloud` should spew errors, and `git annex copy --auto --to cloud` runs without issue. Anything I should do on my end to investigate this issue further?
+
+Thanks,
+
+Andrew
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+"""]]

diff --git a/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn
new file mode 100644
index 0000000..67ba99b
--- /dev/null
+++ b/doc/forum/how_long_are_git_annex_commands_supposed_to_take__63__.mdwn
@@ -0,0 +1,9 @@
+I have a git annex repository that contains only photos and videos. I am using an NTFS partition on Linux (because dual-boot), and recently did a `git annex upgrade` to version 6. (But the question below is general, and not about version 6). The size of my repo must be around 80G.
+
+When I run commands like status and sync, nothing happens for a really long time. I finished a `git annex fsck` today morning after the version upgrade, and so wanted to see what the repo now looks like:
+
+    git annex status --debug
+
+This is stuck at internally calling `git status -uall -z` with some other options. The process is stuck here for almost an hour, and I finally gave up and cancelled it. Like I said, this is not about the recent upgrade that I finished. I have previously seen the process succeed after one or two hours.
+
+Is it normal for `status` to take this long? Or is there something wrong with my repo? For example, maybe a large chunk of my files are checked into git without being annexed? My repo has a long history of making mistakes with git annex, so this is actually possible.

diff --git a/doc/bugs/clash_of_-j__in_copy_for_--json_--json-progress.mdwn b/doc/bugs/clash_of_-j__in_copy_for_--json_--json-progress.mdwn
new file mode 100644
index 0000000..dddcf90
--- /dev/null
+++ b/doc/bugs/clash_of_-j__in_copy_for_--json_--json-progress.mdwn
@@ -0,0 +1,15 @@
+### What version of git-annex are you using? On what operating system?
+
+6.20170101+gitg93d69b1-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex copy --help
+...
+  -j,--json                enable JSON output
+  -j,--json-progress       include progress in JSON output
+
+"""]]
+
+[[!meta author=yoh]]

removed
diff --git a/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment b/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment
deleted file mode 100644
index 53d5983..0000000
--- a/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="pa.aronsson@1f04cce52a3649f5485c62c1f97bf157b1d3ba56"
- nickname="pa.aronsson"
- avatar="http://cdn.libravatar.org/avatar/33eb282dc9247afcffea03dcbe960107"
- subject="Isn't the ending "." in the host name the problem?"
- date="2017-01-20T09:53:56Z"
- content="""
-xmpp.l.google.com.:5222 -> xmpp.l.google.com:5222
-"""]]

Added a comment: Isn't the ending "." in the host name the problem?
diff --git a/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment b/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment
new file mode 100644
index 0000000..53d5983
--- /dev/null
+++ b/doc/bugs/googlemail/comment_3_185feadcfdf1f096dc34d6456a0e2269._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pa.aronsson@1f04cce52a3649f5485c62c1f97bf157b1d3ba56"
+ nickname="pa.aronsson"
+ avatar="http://cdn.libravatar.org/avatar/33eb282dc9247afcffea03dcbe960107"
+ subject="Isn't the ending "." in the host name the problem?"
+ date="2017-01-20T09:53:56Z"
+ content="""
+xmpp.l.google.com.:5222 -> xmpp.l.google.com:5222
+"""]]

add wishlist item
diff --git a/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn b/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn
new file mode 100644
index 0000000..a71aaa3
--- /dev/null
+++ b/doc/todo/wishlist__58___per-repository_autocommit__61__false.mdwn
@@ -0,0 +1,5 @@
+when using git-annex as a minority participant in a repository (eg. because in a hardware project, at some point in time, photos get added), users will start to need to `git annex sync` (because a plain `git pull` / `git push` will work but show errors, and a `pull --all` / `annex merge` is difficult for users to remember). to stay in line with usual git usage, the `sync` must be used with `config annex.autocommit false`, but that needs to be configured on each repository.
+
+forgetting to do that explicit configuration results, in one sync command, easily results in an unwanted implicit commit that's pushed across remotes.
+
+could there be a per-repository option (somewhere around .gitattributes, or maybe in the git-annex branch) that disables autocommits for the repository?

Added a comment
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment
new file mode 100644
index 0000000..b689938
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_3_9d8d03bda09596d03d9cfb7138a152f0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jaylangseth@fa84aeedaf6dd96a51e93b012339ac09fb4dc135"
+ nickname="jaylangseth"
+ avatar="http://cdn.libravatar.org/avatar/a40561e76777f90b29891f8fb86b5d05"
+ subject="comment 3"
+ date="2017-01-18T21:11:15Z"
+ content="""
+Ok!  Got it working, and I can ssh between the two machines and access git-annex-shell on both sides, got all the $PATH stuff right.  I set up one repo on the desktop and one on the server, made them remotes of each other, and I have managed to transfer files back and forth using \"git annex sync.\"  But how do I get the assistant to do this automatically without command line intervention?  Just dropping the file in one folder, it doesn't show up in another, unlike the other git-annex repos I have between my two local computers.
+"""]]

diff --git a/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
new file mode 100644
index 0000000..ab26e2b
--- /dev/null
+++ b/doc/forum/Git-annex_and_Microsoft_Office_files_on_OS_X.mdwn
@@ -0,0 +1 @@
+On OS X 10.11.6, if you save any MS office file (.pptx, .docx, .xlsx) in a git-annex directory it won't be synced unless you restart the daemon.  If you look in the logs it says "/Users/me/annex/test.pptx still has writers, not adding"  This probably has something to do with temporary/lockfiles used by MS office apps.  Any ideas on a workaround, other than restarting the daemon constantly?

Added a comment
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment
new file mode 100644
index 0000000..3b2ba3a
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_dd29ac2b5615ff6f79458a36bce44306._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 4"
+ date="2017-01-18T16:52:21Z"
+ content="""
+Log from other side:
+
+```
+[2017-01-18 15:46:22 MSK] main: starting assistant version 5.20140412ubuntu1
+[2017-01-18 15:46:22 MSK] Cronner: You should enable consistency checking to protect your data. 
+(Recording state in git...)
+(scanning...) [2017-01-18 15:46:22 MSK] Watcher: Performing startup scan
+(started...) 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:
+aa:c0:c3:b8:ca:4d:5c:85:58:02:b6:a0:4a:64:18:dd echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|+B.o .           |
+|B o E .          |
+|.o . . .         |
+|o     .          |
+|.    .  S        |
+| +. .  .         |
+|. =o  .          |
+|..oo .           |
+|+. ..            |
++-----------------+
+[2017-01-18 15:48:26 MSK] main: Pairing in progress
+[2017-01-18 15:48:44 MSK] PairListener: abutirsky@sml-pc-066:~/Desktop/gitrepo_test is sending a pair request.
+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:
+28:e0:f4:a2:2c:a2:bc:7a:22:6e:4c:6d:8f:38:ac:b4 echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|  o              |
+| o o   .         |
+|  + o . S        |
+|.o + .           |
+|Boo o            |
+|O*o. .           |
+|XEo              |
++-----------------+
+[2017-01-18 15:50:40 MSK] main: Pairing with abutirsky@sml-pc-066:~/Desktop/gitrepo_test in progress
+```
+
+By the way, any comment here is accessible for deletion by anyone. Seems like security hole
+"""]]

removed
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment
deleted file mode 100644
index 6e327c0..0000000
--- a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment
+++ /dev/null
@@ -1,53 +0,0 @@
-[[!comment format=mdwn
- username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
- nickname="butirsky"
- avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
- subject="comment 4"
- date="2017-01-18T13:35:18Z"
- content="""
-Log from other side:
-
-```
-[2017-01-18 15:46:22 MSK] main: starting assistant version 5.20140412ubuntu1
-[2017-01-18 15:46:22 MSK] Cronner: You should enable consistency checking to protect your data. 
-(Recording state in git...)
-(scanning...) [2017-01-18 15:46:22 MSK] Watcher: Performing startup scan
-(started...) 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:
-aa:c0:c3:b8:ca:4d:5c:85:58:02:b6:a0:4a:64:18:dd echormonov@sml-pc-091
-The key's randomart image is:
-+--[ RSA 2048]----+
-|+B.o .           |
-|B o E .          |
-|.o . . .         |
-|o     .          |
-|.    .  S        |
-| +. .  .         |
-|. =o  .          |
-|..oo .           |
-|+. ..            |
-+-----------------+
-[2017-01-18 15:48:26 MSK] main: Pairing in progress
-[2017-01-18 15:48:44 MSK] PairListener: abutirsky@sml-pc-066:~/Desktop/gitrepo_test is sending a pair request.
-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:
-28:e0:f4:a2:2c:a2:bc:7a:22:6e:4c:6d:8f:38:ac:b4 echormonov@sml-pc-091
-The key's randomart image is:
-+--[ RSA 2048]----+
-|                 |
-|                 |
-|  o              |
-| o o   .         |
-|  + o . S        |
-|.o + .           |
-|Boo o            |
-|O*o. .           |
-|XEo              |
-+-----------------+
-[2017-01-18 15:50:40 MSK] main: Pairing with abutirsky@sml-pc-066:~/Desktop/gitrepo_test in progress
-```
-"""]]

Added a comment
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment
new file mode 100644
index 0000000..6e327c0
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_4_9f490525f12ec8a925885eef4f22943f._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 4"
+ date="2017-01-18T13:35:18Z"
+ content="""
+Log from other side:
+
+```
+[2017-01-18 15:46:22 MSK] main: starting assistant version 5.20140412ubuntu1
+[2017-01-18 15:46:22 MSK] Cronner: You should enable consistency checking to protect your data. 
+(Recording state in git...)
+(scanning...) [2017-01-18 15:46:22 MSK] Watcher: Performing startup scan
+(started...) 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:
+aa:c0:c3:b8:ca:4d:5c:85:58:02:b6:a0:4a:64:18:dd echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|+B.o .           |
+|B o E .          |
+|.o . . .         |
+|o     .          |
+|.    .  S        |
+| +. .  .         |
+|. =o  .          |
+|..oo .           |
+|+. ..            |
++-----------------+
+[2017-01-18 15:48:26 MSK] main: Pairing in progress
+[2017-01-18 15:48:44 MSK] PairListener: abutirsky@sml-pc-066:~/Desktop/gitrepo_test is sending a pair request.
+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:
+28:e0:f4:a2:2c:a2:bc:7a:22:6e:4c:6d:8f:38:ac:b4 echormonov@sml-pc-091
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|  o              |
+| o o   .         |
+|  + o . S        |
+|.o + .           |
+|Boo o            |
+|O*o. .           |
+|XEo              |
++-----------------+
+[2017-01-18 15:50:40 MSK] main: Pairing with abutirsky@sml-pc-066:~/Desktop/gitrepo_test in progress
+```
+"""]]

Added a comment
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment
new file mode 100644
index 0000000..52c0d81
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_3_d437dc44114f59d5717c177831ae0d53._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 3"
+ date="2017-01-18T13:21:45Z"
+ content="""
+Version of annex on the other side is 5.20140412ubuntu1, if it matters
+"""]]

Added a comment
diff --git a/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment
new file mode 100644
index 0000000..6e73241
--- /dev/null
+++ b/doc/forum/_illegal_control_characters_in_pairing_message__59___ignoring/comment_2_f4dd76879e2b2bd0da557ee6a539533c._comment
@@ -0,0 +1,95 @@
+[[!comment format=mdwn
+ username="butirsky@86ff3803c45a8a1e5fc253d2728ce493c8addf96"
+ nickname="butirsky"
+ avatar="http://cdn.libravatar.org/avatar/bf8e56c57b179935c6f52ebc4690c2bf"
+ subject="comment 2"
+ date="2017-01-18T13:19:43Z"
+ content="""
+Having the same issue, the error only on one side, syncing doesn't start:
+
+```
+[2017-01-18 15:25:30.603909] main: starting assistant version 5.20151208-1build1
+[2017-01-18 15:25:30.615017] Cronner: You should enable consistency checking to protect your data. 
+
+  No known volume monitor available through dbus; falling back to mtab polling
+(scanning...) [2017-01-18 15:25:31.040087] Watcher: Performing startup scan
+(started...) 
+(scanning...) [2017-01-18 15:27:19.254315] Watcher: Performing startup scan
+(started...) git-annex: Daemon is already running.
+warning: no common commits
+From /home/abutirsky/Desktop/annex
+ * [new branch]      annex/direct/master -> annex/annex/direct/master
+ * [new branch]      git-annex  -> annex/git-annex
+ * [new branch]      master     -> annex/master
+
+(merging annex/git-annex into git-annex...)
+(recording state in git...)
+
+Already up-to-date!
+Merge made by the 'recursive' strategy.
+[2017-01-18 15:29:18.003333] main: Syncing with annex 
+[2017-01-18 15:29:18.003518] Pusher: Syncing with annex 
+To /home/abutirsky/Desktop/annex
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+Everything up-to-date
+
+(nautilus:19391): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
+
+(nautilus:19391): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
+
+(nautilus:19391): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
+
+(nautilus:19391): GLib-GObject-WARNING **: invalid (NULL) pointer instance
+
+(nautilus:19391): GLib-GObject-CRITICAL **: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
+git-annex: Daemon is already running.
+(scanning...) [2017-01-18 15:34:47.539423] Watcher: Performing startup scan
+(started...) git-annex: Daemon is already running.
+git-annex: Daemon is already running.
+git-annex: Daemon is already running.
+
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+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:
+SHA256:dJ9VU8CQ+hHL2fsta1E5PkxTvkqDThbyOainUXZvaY4 abutirsky@sml-pc-066
+The key's randomart image is:
++---[RSA 2048]----+
+|            .+.o+|
+|            o ..o|
+|        . .o =..o|
+|       . o.o=o.=o|
+|        So+o*.+o+|
+|        o..Boo+= |
+|       .. + o=ooo|
+|       ... .=.o o|
+|       .o  E o.o |
++----[SHA256]-----+
+[2017-01-18 15:48:44.423064] main: Pairing in progress
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+
+  illegal control characters in pairing message; ignoring
+```
+"""]]

Fixes ToC
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
index 51cdf93..127acc8 100644
--- a/doc/tips/antipatterns.mdwn
+++ b/doc/tips/antipatterns.mdwn
@@ -13,7 +13,7 @@ possible ways of doing things.
 
 ---
 
-# **Antipattern**
+# **Symlinking the `.git/annex` directory**
 
 Symlinking the `.git/annex` directory, in the hope of saving
 disk space, is a horrible idea. The general antipattern is:
@@ -54,9 +54,7 @@ we can do to change that in this case.
 
 ---
 
-# **Antipattern**
-
-Reinit repo with an existing uuid without fsck
+# **Reinit repo with an existing uuid without `fsck`**
 
 To quote the [[git-annex-reinit]] manpage:
 

backwards links again
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
index 21d2a53..51cdf93 100644
--- a/doc/tips/antipatterns.mdwn
+++ b/doc/tips/antipatterns.mdwn
@@ -90,7 +90,7 @@ Fixes
 -----
 
 An improvement to git-annex here would be to allow
-[[todo/reinit_should_work_without_arguments|reinit to work without arguments]]
+[[reinit to work without arguments|todo/reinit_should_work_without_arguments]]
 to at least not encourage UUID reuse. reinit could also recommend
 running fsck explicitely. It could even trigger an fsck directly.
 

fix link
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
index 8e8a98a..21d2a53 100644
--- a/doc/tips/antipatterns.mdwn
+++ b/doc/tips/antipatterns.mdwn
@@ -3,7 +3,7 @@ git-annex in the past that can lead to catastrophic data loss, abusive
 disk usage, improper swearing and other unfortunate experiences.
 
 This could also be called the "git annex worst practices", but is
-different than [[not|what git annex is not]] in that it covers normal
+different than [[what git annex is not|not]] in that it covers normal
 use cases of git-annex, just implemented in the wrong way. Hopefully,
 git-annex should make it as hard as possible to do those things, but
 sometimes, you just can't help it, people figure out the worst

Page flow and antipattern separation
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
index 04504ac..8e8a98a 100644
--- a/doc/tips/antipatterns.mdwn
+++ b/doc/tips/antipatterns.mdwn
@@ -11,13 +11,11 @@ possible ways of doing things.
 
 [[!toc]]
 
-.git/annex symlink
-==================
+---
 
-Antipattern
------------
+# **Antipattern**
 
-Symlinking the `.git/annex` symlink directory, in the hope of saving
+Symlinking the `.git/annex` directory, in the hope of saving
 disk space, is a horrible idea. The general antipattern is:
 
     git clone repoA repoB
@@ -54,8 +52,11 @@ Probably no way to fix this in git-annex - if users want to shoot
 themselves in the foot by messing with the backend, there's not much
 we can do to change that in this case.
 
-using reinit with an existing uuid without fsck
-===============================================
+---
+
+# **Antipattern**
+
+Reinit repo with an existing uuid without fsck
 
 To quote the [[git-annex-reinit]] manpage:
 
@@ -64,9 +65,6 @@ To quote the [[git-annex-reinit]] manpage:
 > to reuse a UUID -- for example, if a repository got deleted, and
 > you're setting it back up.
 
-Anti-pattern
-------------
-
 [[git-annex-reinit]] can be used to reuse UUIDs for deleted
 repositories. But what happens if you reuse the UUID of an *existing*
 repository, or a repository that hasn't been properly emptied before

note an improvement on the reinit manpage
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
index bea144d..04504ac 100644
--- a/doc/tips/antipatterns.mdwn
+++ b/doc/tips/antipatterns.mdwn
@@ -57,7 +57,7 @@ we can do to change that in this case.
 using reinit with an existing uuid without fsck
 ===============================================
 
-To quote the manpage:
+To quote the [[git-annex-reinit]] manpage:
 
 > Normally, initializing a repository generates a new, unique
 > identifier (UUID) for that repository. Occasionally it may be useful
@@ -96,6 +96,9 @@ An improvement to git-annex here would be to allow
 to at least not encourage UUID reuse. reinit could also recommend
 running fsck explicitely. It could even trigger an fsck directly.
 
+The [[git-annex-reinit]] manpage has always suggested running `fsck`,
+but the wording has been changed on 2017-01-17.
+
 Other cases
 ===========
 

use stronger wording in reinit regarding fsck
diff --git a/doc/git-annex-reinit.mdwn b/doc/git-annex-reinit.mdwn
index 1ca8227..52bca57 100644
--- a/doc/git-annex-reinit.mdwn
+++ b/doc/git-annex-reinit.mdwn
@@ -14,8 +14,10 @@ UUID -- for example, if a repository got deleted, and you're
 setting it back up.
 
 Use this with caution; it can be confusing to have two existing
-repositories with the same UUID. Also, you will probably want to run
-a fsck.
+repositories with the same UUID. It can lead to data loss and other
+weird phenomenons. Make sure you run `git annex fsck` after changing
+the UUID of a repository to make sure location tracking information is
+recorded correctly.
 
 Like `git annex init`, this attempts to enable any special remotes
 that are configured with autoenable=true.
@@ -26,6 +28,8 @@ that are configured with autoenable=true.
 
 [[git-annex-init]](1)
 
+[[git-annex-fsck]](1)
+
 # AUTHOR
 
 Joey Hess <id@joeyh.name>

a list of problems i had with git-annex
diff --git a/doc/tips/antipatterns.mdwn b/doc/tips/antipatterns.mdwn
new file mode 100644
index 0000000..bea144d
--- /dev/null
+++ b/doc/tips/antipatterns.mdwn
@@ -0,0 +1,106 @@
+This page tries to regroup a set of Really Bad Ideas people had with
+git-annex in the past that can lead to catastrophic data loss, abusive
+disk usage, improper swearing and other unfortunate experiences.
+
+This could also be called the "git annex worst practices", but is
+different than [[not|what git annex is not]] in that it covers normal
+use cases of git-annex, just implemented in the wrong way. Hopefully,
+git-annex should make it as hard as possible to do those things, but
+sometimes, you just can't help it, people figure out the worst
+possible ways of doing things.
+
+[[!toc]]
+
+.git/annex symlink
+==================
+
+Antipattern
+-----------
+
+Symlinking the `.git/annex` symlink directory, in the hope of saving
+disk space, is a horrible idea. The general antipattern is:
+
+    git clone repoA repoB
+    mv repoB/.git/annex repoB/.git/annex.bak
+    ln -s repoA/.git/annex repoB/.git/annex
+
+This is bad because git-annex will believe it has two copy of the
+files and then would let you drop the single copy, therefore leading
+to data loss.
+
+Proper pattern
+--------------
+
+The proper way of doing this is through git-annex's hardlink support,
+by cloning the repository with the `--shared` option:
+
+    git clone --shared repoA repoB
+
+This will setup repoB as an "untrusted" repository and use hardlinks
+to copy files between the two repos, using space only once. This
+works, of course, only on filesystems that support hardlinks, but
+that's usually the case for filesystems that support symlinks.
+
+Real world cases
+----------------
+
+ * [[forum/share_.git__47__annex__47__objects_across_multiple_repositories_on_one_machine/]]
+ * at least one IRC discussion
+
+Fixes
+-----
+
+Probably no way to fix this in git-annex - if users want to shoot
+themselves in the foot by messing with the backend, there's not much
+we can do to change that in this case.
+
+using reinit with an existing uuid without fsck
+===============================================
+
+To quote the manpage:
+
+> Normally, initializing a repository generates a new, unique
+> identifier (UUID) for that repository. Occasionally it may be useful
+> to reuse a UUID -- for example, if a repository got deleted, and
+> you're setting it back up.
+
+Anti-pattern
+------------
+
+[[git-annex-reinit]] can be used to reuse UUIDs for deleted
+repositories. But what happens if you reuse the UUID of an *existing*
+repository, or a repository that hasn't been properly emptied before
+being declared dead? This can lead to data loss because, in that case,
+git-annex may think some files are still present in the revived
+repository (while they may not actually be).
+
+Proper pattern
+--------------
+
+The proper way of using reinit is to make sure you run
+[[git-annex-fsck]] (optionally with `--fast` to save time) on the
+revived repo right after running reinit. This will ensure that at
+least the location log will be updated, and git-annex will notice if
+files are missing.
+
+Real world cases
+----------------
+
+ * [[bugs/remotes_disappeared]]
+
+Fixes
+-----
+
+An improvement to git-annex here would be to allow
+[[todo/reinit_should_work_without_arguments|reinit to work without arguments]]
+to at least not encourage UUID reuse. reinit could also recommend
+running fsck explicitely. It could even trigger an fsck directly.
+
+Other cases
+===========
+
+Feel free to add your lessons in catastrophe here! It's educational
+and fun, and will improve git-annex for everyone.
+
+PS: should this be a toplevel page instead of being drowned in the
+[[tips]] section? Where should it be linked to?  -- [[anarcat]]

link to the workflow page
diff --git a/doc/todo/build_a_user_guide.mdwn b/doc/todo/build_a_user_guide.mdwn
index 9741439..44b350e 100644
--- a/doc/todo/build_a_user_guide.mdwn
+++ b/doc/todo/build_a_user_guide.mdwn
@@ -1,3 +1,5 @@
 there's a lot of good documentation on this wiki, but it's hard to find sometimes. it's also unclear if we should look in the [[git-annex]] manpage or elsewhere in the wiki or where. this is a typical problem with the use of wikis for documentation: it's there, but hard to find. it doesn't mean a wiki shouldn't be used but, as with any user manual, special care needs to be taken about structure, organisation and making sure the manual is exhaustive.
 
 a good example of this problem is [[todo/document_standard_groups_more_extensively_in_the_UI]]. --[[anarcat]]
+
+update: a beginning of this may be the the [[workflow]] page but it lacks a lot of details... 

Added a comment: answers
diff --git a/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment b/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment
new file mode 100644
index 0000000..01ad920
--- /dev/null
+++ b/doc/todo/Workflow_guide/comment_7_805e877b23adcf562feeb7d927fca08d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="answers"
+ date="2017-01-17T16:56:39Z"
+ content="""
+i actually answered this in [[forum/Full_workflow_guide]] before realizing this post was a duplicate.
+
+i am not sure where that should be put - it's not a \"full workflow guide\", it's actually a \"specific workflow guide\", namely \"i have 3 computers and need to sync files from A to B to C\"... 
+
+i wonder if this should be marked as resolved or if we want to add a specific workflow for this or what?
+
+this reminds me of my broader [[todo/build_a_user_guide]] task... -- [[anarcat]]
+"""]]

Added a comment: hopefully an answer...
diff --git a/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment b/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment
new file mode 100644
index 0000000..320dd6b
--- /dev/null
+++ b/doc/forum/Full_workflow_guide/comment_1_14664efebb1218a1449577eaa4653a77._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="hopefully an answer..."
+ date="2017-01-17T16:54:22Z"
+ content="""
+looking at the page title here, i'm tempted to simply point you to [[todo/Workflow_guide]] and therefore the new [[workflow]] page, but that may not answer your question directly. so let's see...
+
+the the examples below, i'll assume you are familiar with the commandline and show examples using git and git-annex commands, since you mentioned that. but a lot of those things can be done with the web assistant, if not everything. but i am not very familiar with it, so you'll excuse my geekiness...
+
+1. I want to start keeping track of some files I have in a directory
+
+        cd directory
+        git init
+        git annex init
+        git annex add \"some\" \"files\"
+        git commit -m\"start keeping track of some files\"
+
+    Note that you could track all files with `git annex add .` or `git annex add *`... regular glob patterns apply.
+
+2. I want to copy them to a second computer.
+
+    This is the harder part. Here I'll assume that you have an SSH server on the first computer, which i'll name `firstcomputer`. If that's not your case, you can use the new [[special_remotes/tor]] to pair arbitrary machines with the [[tips/peer_to_peer_network_with_tor]] instructions instead of this.
+
+    On the second computer:
+
+        git clone firstcomputer:directory
+        cd directory
+        git annex get
+
+3. From a third place, I want to get them from the second computer.
+
+    Same comments as above apply.
+
+    On the third computer:
+
+        git clone secondcomputer:directory
+        cd directory
+        git annex get
+
+4. I change the files on one computer, and I want to make sure the changes get synced to the others.
+
+    This can be done manually with [[git-annex-sync]] (with the `--content` flag to copy actual content), or automated with the [[git-annex-assistant]] or [[git-annex-watch]].
+"""]]

Added a comment
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment
new file mode 100644
index 0000000..7234852
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_2_6450ee0b5729beec155fbe0ce304e223._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jaylangseth@fa84aeedaf6dd96a51e93b012339ac09fb4dc135"
+ nickname="jaylangseth"
+ avatar="http://cdn.libravatar.org/avatar/a40561e76777f90b29891f8fb86b5d05"
+ subject="comment 2"
+ date="2017-01-17T16:37:39Z"
+ content="""
+Ok thanks!  I'll give that a try.
+"""]]

Added a comment: re dataloss and point
diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment
new file mode 100644
index 0000000..39bac18
--- /dev/null
+++ b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_7_10086c35bbd54e502303a8763cc06afd._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="re dataloss and point"
+ date="2017-01-17T01:34:43Z"
+ content="""
+I think you wouldn't have had data loss if you untrusted the repository, am I correct? The remote is explicitly marked as \"unsafe\" (and ideally, it would automatically declare that to git-annex, but maybe there's no way to setup the trust level of remotes automatically like that) so operations that *move* files to it will be denied unless there's another copy somewhere...
+
+As for \"what's the point of it\", I thought I made that pretty clear... It enables use cases like:
+
+* [[forum/syncing_music_to_my_android_device/]]
+* [[forum/original_filename_on_s3/]]
+* [[todo/Facilitate_public_pretty_S3_URLs]]
+* etc
+
+> Aside from data loss bugs, /tmp/dumb just can't be kept fully up-to-date with changes to the working tree. So what's the point of it?
+
+I'm not sure what you mean there, by \"can't be kept fully up up-to-date\", could you clarify?
+
+Do you mean it won't follow renames and such? In my use case, I don't mind: i can just trash the remote and recreate it, if the working tree changes - and it doesn't change often enough for this to be a problem.
+
+> After fixing its calckey to work with the current version of git-annex...
+
+would you mind sharing that fix? :)
+
+thanks for the feedback, and sorry for the delay - for some reason i never got notifications for the reply... :/
+"""]]

diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn b/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn
new file mode 100644
index 0000000..b013ebb
--- /dev/null
+++ b/doc/bugs/fatal__58___unable_to_normalize_object_directory.mdwn
@@ -0,0 +1,80 @@
+### Please describe the problem.
+
+I'm getting `fatal: unable to normalize object directory` while issuing `git annex copy` from an annex in my laptop to a vanilla remote annex located in a USB disk.
+As far as I can tell there are no hardware problems with the disk or the laptop.
+
+```
+$ git annex copy --auto --to usbdrive .
+copy vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts (to usbdrive...) 
+SHA256E-s1256869488--28edfd2c4eb08e6782c806a85db7bc10595c16df6f64d3d46ebc2802b3ba5038.ts
+  1,256,869,488 100%   52.96MB/s    0:00:22 (xfr#1, to-chk=0/1)
+(checksum...) fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+
+  fd:24: hGetLine: end of file
+
+SHA256E-s1256869488--28edfd2c4eb08e6782c806a85db7bc10595c16df6f64d3d46ebc2802b3ba5038.ts
+  1,256,869,488 100%   56.08MB/s    0:00:21 (xfr#1, to-chk=0/1)
+(checksum...) 
+  fd:23: hFlush: resource vanished (Broken pipe)
+
+  fd:23: hClose: resource vanished (Broken pipe)
+ok
+(recording state in git...)
+```
+
+But note that the command did not abort. After copying, `fsck` reports no error:
+
+```
+$ git annex fsck --from=usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts'
+fsck vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts (checksum...) ok
+(recording state in git...)
+```
+
+I get the same errors with `drop`, which fails: 
+
+```
+$ git annex drop --from usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts'
+drop usbdrive vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+fatal: unable to normalize object directory: /home/jr/Videos/ts/../../../../../run/media/jr/TOSHIBA/jr/Videos.git/objects
+
+git-annex: fd:27: hGetLine: end of file
+failed
+git-annex: drop: 1 failed
+```
+
+But the same `drop` works if executed again:
+
+```
+$ git annex drop --from usbdrive 'vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts'
+drop usbdrive vlc-record-2016-07-17-15h16m55s-hr-fernsehen-Die fantastische Reise der Vögel (3_6).ts ok
+(recording state in git...)
+```
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20161231-gc8eeb17da
+
+Linux XXX 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64 GNU/Linux
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes! I use git-annex without a problem since years. This is the first time I have really no idea what's going on.

Added a comment: Can git-annex be used to quasi-realtime replication?
diff --git a/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment b/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment
new file mode 100644
index 0000000..1955a94
--- /dev/null
+++ b/doc/not/comment_16_d2ae9613ad81508dbda6ed425d441ccb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="shodanshok@8c8405b6944c211be7dec8ae8fccde70adc19027"
+ nickname="shodanshok"
+ avatar="http://cdn.libravatar.org/avatar/8b4dd6a9f2396b788ca18f3690609ad3"
+ subject="Can git-annex be used to quasi-realtime replication?"
+ date="2017-01-16T17:41:07Z"
+ content="""
+Suppose I have two Samba fileservers in two different locations. Can I use git-annex in thin mode + git-annex assistant to automatically synchronize these two fileserver? Specifically, I am trying to understand if:
+
+1) git-annex preserve owner/group ID and POSIX ACLs;
+2) it can efficiently manage very large number of file/directory (500K+ files)
+3) it can be used alongside inotify to efficiently transfer only changed files
+
+One last thing: I which sense git-annex is not like Unison? It seems it can be configured to have very similar functionality. I am missing something?
+
+Thank you all.
+"""]]

Added a comment
diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment
new file mode 100644
index 0000000..eb33165
--- /dev/null
+++ b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_2_0bc9c0e6d72d6b0d9173e55eca8b107a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 2"
+ date="2017-01-16T12:48:36Z"
+ content="""
+how do I move the bug to done?
+"""]]

Added a comment
diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment
new file mode 100644
index 0000000..700e234
--- /dev/null
+++ b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable/comment_1_5a1f9a2014501072188fb235f1b03726._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 1"
+ date="2017-01-16T12:47:03Z"
+ content="""
+Fixed by upgrading to newer version !  Sorry for the re-bug.
+"""]]

Added a comment
diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment
new file mode 100644
index 0000000..fa475cb
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote/comment_1_b2f7b4aa5e7c859de9741db440292365._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 1"
+ date="2017-01-16T12:29:59Z"
+ content="""
+It sounds like you want to have a git-annex working directory on the server.
+
+You can put git-annex on the server without root access.  Just place it in a user folder such as ~/local .
+"""]]

Added a comment
diff --git a/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment
new file mode 100644
index 0000000..9702646
--- /dev/null
+++ b/doc/forum/Shared_repository_without_git-annex_on_central_server/comment_1_286c963b30eee46b261d64937cf66d06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="comment 1"
+ date="2017-01-16T12:16:37Z"
+ content="""
+You can set the server up as a normal git remote to store file changelogs, and then also as an rsync special remote to store file data.  See https://git-annex.branchable.com/special_remotes/rsync/
+"""]]

diff --git a/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn
new file mode 100644
index 0000000..ec4e8be
--- /dev/null
+++ b/doc/bugs/Assumes_OpenSSH_version_newer_than_debian_stable.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+Git-annex is hanging for me on all operations if I have a customized OpenSSH host as a remote.
+This is because git-annex uses a custom config file that uses directives introduced in OpenSSH 7.3p1 .  I have OpenSSH 6.7p1 .
+
+### What steps will reproduce the problem?
+On Debian Jessie, specify a custom host in ~/.ssh/config such as
+
+     Host custom-host
+          HostName realhost.com
+
+Add it as a remote and try to use git-annex
+
+     $ git remote add custom user@custom-host
+     $ git annex vicfg --debug
+
+It just hangs.
+
+### What version of git-annex are you using? On what operating system?
+     git-annex version: 6.20161211-gc3ab3c668
+     PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
+
+### 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
+
+annex@host:~/annex$ git annex vicfg --debug
+[2017-01-16 12:01:58.104071891] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2017-01-16 12:01:58.110698965] process done ExitSuccess
+[2017-01-16 12:01:58.11093666] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2017-01-16 12:01:58.116640973] process done ExitSuccess
+[2017-01-16 12:01:58.123254411] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2017-01-16 12:01:58.125003224] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+[2017-01-16 12:01:58.131239655] read: ssh ["-S",".git/annex/ssh/annex@annex-whonix-standalone","-o","ControlMaster=auto","-o","ControlPersist=yes","-F",".git/annex/ssh.config","-T","annex@annex-whonix-standalone","git-annex-shell 'configlist' '/~/annex' '--debug'"]
+^C
+annex@host:~/annex$ cat .git/annex/ssh.config 
+IgnoreUnknown Include
+Include ~/.ssh/config
+Include /etc/ssh/ssh_config
+ServerAliveInterval 60
+
+# End of transcript or log.
+"""]]
+
+The problem is the use of the `Include` directive which is not understood by my release of OpenSSH.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Git-annex rocks !!!!
+

Add comment at the start of the bug report
f83746bc-dbe0-11e6-8cb8-f74d993421b0
diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn
index 168f6f4..5acf5f0 100644
--- a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn
+++ b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn
@@ -1,3 +1,6 @@
+(Found the problem, so you might want to skip to the comments to see 
+what's wrong.)
+
 ### Please describe the problem.
 
 Trying to drop the contents of 131 files in a subdirectory, but it dies 

Added a comment: Wrong permissions
diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment
new file mode 100644
index 0000000..b3e5b8a
--- /dev/null
+++ b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_2_9a0fec331a858746e2fecc6b86ab8cbb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sunny256"
+ avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4"
+ subject="Wrong permissions"
+ date="2017-01-16T11:17:31Z"
+ content="""
+Yes, confirmed. I tried to create a new test repository and chmod all directories with +s. I'm using umask 0002, so new files are created with perm 0664 and the correct shared group. But the SQLite files in .git/annex/keys/ are created with permission 0644, so other users in the group are not able to update the files there.
+"""]]

Added a comment: Found the reason
diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment
new file mode 100644
index 0000000..7c9caf0
--- /dev/null
+++ b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents/comment_1_cd09e4d4a73e003735e3297922b8faa8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sunny256"
+ avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4"
+ subject="Found the reason"
+ date="2017-01-16T11:03:45Z"
+ content="""
+I managed to find the reason why it failed. The files in .git/annex/keys/ had wrong permissions, so I wasn't able to write to them. This is a shared repository where everyone within the Unix group can read and write. All the directories including .git/annex/keys have chmod +s so any additions or edits are stored within the correct group. But the SQLite files were stored with permission 0644 instead of 0664, and my umask in the shell is 0002. Maybe SQLite is creating the database with wrong permissions?
+"""]]

Added a comment
diff --git a/doc/todo/Alternative_mode_control_for_import/comment_1_77dc4b03e243d46c227f43cb3f573ec0._comment b/doc/todo/Alternative_mode_control_for_import/comment_1_77dc4b03e243d46c227f43cb3f573ec0._comment
new file mode 100644
index 0000000..7b94f92
--- /dev/null
+++ b/doc/todo/Alternative_mode_control_for_import/comment_1_77dc4b03e243d46c227f43cb3f573ec0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 1"
+ date="2017-01-16T10:30:55Z"
+ content="""
+This [[TODO|todo/import_--reinject/]] (and \"reinject --known\") would then be:
+
+    git annex import --mode=Did
+
+"""]]

diff --git a/doc/todo/Alternative_mode_control_for_import.mdwn b/doc/todo/Alternative_mode_control_for_import.mdwn
new file mode 100644
index 0000000..24bbd5a
--- /dev/null
+++ b/doc/todo/Alternative_mode_control_for_import.mdwn
@@ -0,0 +1,17 @@
+This suggestion has come from being surprised at the behaviour of "import --skip-duplicates" which copies files instead of moving them and leaves the source directory untouched (description implies it will just leave duplicates alone).
+
+Apologies for the brevity, I've already typed this out once..
+
+"import" has several behaviours which can be controlled through some options, but they don't cover all wanted behaviours. This suggestion is for an alternative interface to control these behaviours, totally stolen from rsync :P
+
+    # create symlinks (s), inject content (i) and delete from source (d)
+    # duplicate (D) and new (N) files
+    git annex import --mode=Dsid,Nsid $src # (default behaviour)
+    git annex import --mode=Dsi,Nsi $src   # --duplicate
+    git annex import --mode=Dd,Nsid $src   # --deduplicate
+    git annex import --mode=Nsi $src       # --skip-duplicates
+    git annex import --mode=Dd $src        # --clean-duplicates
+    git annex import --mode=Did,Nsid $src  # (import new, reinject duplicate.. really want this!)
+    git annex import --mode=Ns $src        # (just creates symlinks for new)
+    git annex import --mode=Nsd $src       # (invalid mode due to data loss)
+    git annex import --mode=Nid $src       # (invalid or require --force)

Add bug report about SQLite error
diff --git a/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn
new file mode 100644
index 0000000..168f6f4
--- /dev/null
+++ b/doc/bugs/Aborts_with_SQLite_error_when_dropping_contents.mdwn
@@ -0,0 +1,80 @@
+### Please describe the problem.
+
+Trying to drop the contents of 131 files in a subdirectory, but it dies 
+with an "sqlite worker thread crashed" error. The contents of one file 
+is deleted, and then it dies. The files in that directory are exactly 1G 
+(1000000000) bytes each.
+
+There's no data loss here, it creates files in `.git/annex/journal/` 
+which is added to the git-annex branch after a git annex sync. "git 
+annex fsck --fast --quiet" is happy and finds no errors.
+
+### What steps will reproduce the problem?
+
+"git annex drop" with and without --force. Tried to copy one of the 
+files to another server with Debian 8.7, and it's successfully dropped 
+there. Same git-annex version.
+
+### What version of git-annex are you using? On what operating system?
+
+OS: Ubuntu 14.04.5 LTS
+
+git-annex: 6.20161211-gc3ab3c668 (from 
+`git-annex-standalone-amd64.tar.gz` in the annex at 
+downloads.kitenet.net)
+
+I have compiled the newest sqlite3 3.16.2 and placed it in 
+/usr/local/bin/, just mentioning it because it's some kind of SQLite 
+error. but executing the command with a PATH without /usr/local/bin 
+makes no difference.
+
+### Please provide any additional information below.
+
+# 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 drop -d --force
+    [2017-01-16 08:58:39.947856861] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","ls-files","--cached","-z","--"]
+    [2017-01-16 08:58:39.953150944] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+    [2017-01-16 08:58:39.953742873] read: git ["--version"]
+    [2017-01-16 08:58:39.959438053] process done ExitSuccess
+    [2017-01-16 08:58:39.959919735] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","git-annex"]
+    [2017-01-16 08:58:39.963707897] process done ExitSuccess
+    [2017-01-16 08:58:39.963882344] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2017-01-16 08:58:39.967078602] process done ExitSuccess
+    [2017-01-16 08:58:39.969062554] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch"]
+    [2017-01-16 08:58:39.970168767] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+    drop MyStream_3/MyStream_3.mp4.split_ag [2017-01-16 08:58:39.984359273] Dropping from here proof: Nothing
+    sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from content limit 1": unable to open database file
+    ok
+    git-annex: thread blocked indefinitely in an MVar operation
+    $ git annex drop -d --force
+    [2017-01-16 08:58:58.890031175] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","ls-files","--cached","-z","--"]
+    [2017-01-16 08:58:58.895047131] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"]
+    [2017-01-16 08:58:58.895690334] read: git ["--version"]
+    [2017-01-16 08:58:58.901206493] process done ExitSuccess
+    [2017-01-16 08:58:58.901836453] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","git-annex"]
+    [2017-01-16 08:58:58.905632574] process done ExitSuccess
+    [2017-01-16 08:58:58.905793223] read: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2017-01-16 08:58:58.909227509] process done ExitSuccess
+    [2017-01-16 08:58:58.910902084] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch"]
+    [2017-01-16 08:58:58.912164764] chat: git ["--git-dir=../../../../../../../.git","--work-tree=../../../../../../..","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)"]
+    drop MyStream_3/MyStream_3.mp4.split_ah [2017-01-16 08:58:58.927477693] Dropping from here proof: Nothing
+    sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from content limit 1": unable to open database file
+    ok
+    git-annex: thread blocked indefinitely in an MVar operation
+    $
+
+# End of transcript or log.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Indeed. All my stuff (around 3.5 terabytes) is stored in git-annex with 
+at least three copies of each file on different disks and locations, 
+spread over various hard disks, memory sticks, servers and you name it. 
+Unused disk space is a waste, so I fill everything up to the brim with 
+extra copies.
+
+In other words, Git-Annex and I are very happy together, and I'd like to 
+marry it. And because you are the father, I hereby respectfully ask for 
+your blessing.

Added a comment: Long Path Tool
diff --git a/doc/todo/Allow_globally_limiting_filename_length/comment_6_e30124b8837a8956607164e4632502cd._comment b/doc/todo/Allow_globally_limiting_filename_length/comment_6_e30124b8837a8956607164e4632502cd._comment
new file mode 100644
index 0000000..b7f769e
--- /dev/null
+++ b/doc/todo/Allow_globally_limiting_filename_length/comment_6_e30124b8837a8956607164e4632502cd._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="rivera15071976@36a85c6f19ac15f9202999a3e3b15b27cc8a750a"
+ nickname="rivera15071976"
+ avatar="http://cdn.libravatar.org/avatar/e1ab4ef44104ce26ef4b31130b36bfe7"
+ subject="Long Path Tool"
+ date="2017-01-16T08:02:52Z"
+ content="""
+I would recommend you to use Long Path Tool
+"""]]

Added a comment: Oh yes
diff --git a/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment b/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment
new file mode 100644
index 0000000..809e651
--- /dev/null
+++ b/doc/todo/termux_package/comment_1_713568120dda33b83d02408ed9321fb8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sunny256"
+ avatar="http://cdn.libravatar.org/avatar/8a221001f74d0e8f4dadee3c7d1996e4"
+ subject="Oh yes"
+ date="2017-01-16T07:56:59Z"
+ content="""
+That would be great. I'm not very fond of Android because it's only a crippled Linux, but Termux has made my life with Android much better, almost like in the old days on my Nokia N900, R.I.P. :'( I often sync files between the mobile and laptop, and being able to do that in Termux from the command line would be totally awesome.
+"""]]

diff --git a/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn b/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn
index d27aae5..0914278 100644
--- a/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn
+++ b/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn
@@ -178,4 +178,4 @@ git-annex: get: 1 failed
 
 ### Conclusion
 
-I'm so attracted to git-annex's idea, but seems it's still not robust enough to use on Windows platform - v5 direct mode repo is as far as I can get, yet it still throws away my data like this...
+I'm so attracted to git-annex's idea, but so sad it's still not robust enough to use on Windows platform - v5 direct mode repo is as far as I can get, yet it still throws away my data like this...

diff --git a/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn b/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn
new file mode 100644
index 0000000..d27aae5
--- /dev/null
+++ b/doc/bugs/data_loss_on_Windows__58___git_annex_sync_--no-content_drops_last_copy_unexpectedly.mdwn
@@ -0,0 +1,181 @@
+### Please describe the problem.
+A seemingly harmless script causes data loss by dropping last copy of file content.
+
+In my test this script only drops file content on Windows. On Linux it's working good, even on a crippled filesystem.
+
+### What steps will reproduce the problem?
+run the following script test.sh:
+[[!format sh """
+mkdir a
+cd a
+git init
+git annex init first
+mkdir folder
+echo foo > folder/1.txt
+git annex add .
+git annex sync
+cd ..
+git clone a b
+cd b
+git annex init second
+git annex sync
+cd ../a
+git remote add second ../b
+git annex sync
+git annex move --to second
+git annex sync
+mv folder folder1
+git annex add
+git annex sync
+cd ../b
+git annex sync
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 6.20161231-gc8eeb17
+
+Windows 10.0.14393 and also Windows 8
+
+### Please provide any additional information below.
+
+[[!format sh """
+# a complete transcript of the problem occurring.
+$ ./test.sh
+Initialized empty Git repository in A:/a/.git/
+init first
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Enabling direct mode.
+ok
+(recording state in git...)
+add folder/1.txt ok
+(recording state in git...)
+commit  ok
+Cloning into 'b'...
+done.
+init second
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Enabling direct mode.
+ok
+(recording state in git...)
+commit  ok
+pull origin
+ok
+push origin
+Counting objects: 6, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (6/6), 664 bytes | 0 bytes/s, done.
+Total 6 (delta 0), reused 0 (delta 0)
+To A:/a
+ * [new branch]      git-annex -> synced/git-annex
+ok
+commit  ok
+pull second
+From ../b
+ * [new branch]      annex/direct/master -> second/annex/direct/master
+ * [new branch]      git-annex           -> second/git-annex
+ * [new branch]      master              -> second/master
+ * [new branch]      synced/master       -> second/synced/master
+ok
+move folder/1.txt (to second...)
+1.txt
+              4 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/1)
+(checksum...) ok
+(recording state in git...)
+commit  ok
+pull second
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 5 (delta 1), reused 0 (delta 0)
+Unpacking objects: 100% (5/5), done.
+From ../b
+   fd774cb..1aba4de  git-annex  -> second/git-annex
+ok
+(merging second/git-annex into git-annex...)
+(recording state in git...)
+push second
+Counting objects: 10, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (8/8), done.
+Writing objects: 100% (10/10), 827 bytes | 0 bytes/s, done.
+Total 10 (delta 3), reused 0 (delta 0)
+To ../b
+ * [new branch]      git-annex -> synced/git-annex
+ok
+add folder1/1.txt ok
+(recording state in git...)
+commit  (recording state in git...)
+ok
+pull second
+ok
+push second
+Counting objects: 7, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (7/7), 687 bytes | 0 bytes/s, done.
+Total 7 (delta 0), reused 0 (delta 0)
+To ../b
+   7ba3e8a..ee8025b  git-annex -> synced/git-annex
+   0758cf9..6e91185  annex/direct/master -> synced/master
+ok
+commit  ok
+merge synced/master
+Updating 0758cf9..6e91185
+Fast-forward
+ {folder => folder1}/1.txt | 0
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename {folder => folder1}/1.txt (100%)
+error: duplicate parent 6e91185c7c64569b275a09be1a104a1d8955e1fb ignored
+ok
+pull origin
+From A:/a
+   0758cf9..6e91185  annex/direct/master -> origin/annex/direct/master
+   fd774cb..ee8025b  git-annex           -> origin/git-annex
+   0758cf9..6e91185  master              -> origin/master
+   0758cf9..6e91185  synced/master       -> origin/synced/master
+ok
+push origin
+Counting objects: 1, done.
+Writing objects: 100% (1/1), 185 bytes | 0 bytes/s, done.
+Total 1 (delta 0), reused 0 (delta 0)
+To A:/a
+   fd774cb..ee8025b  git-annex -> synced/git-annex
+   6e91185..a886805  annex/direct/master -> synced/master
+ok
+
+$ # script done here
+$ cd b
+$ git annex whereis
+whereis folder1/1.txt (1 copy)
+        2a9ef292-1729-4533-ac50-f68d2d0badb6 -- second [here]
+ok
+
+$ cat folder1/1.txt
+../.git/annex/objects/W5/55/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.txt/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.txt
+
+$ git annex get
+get folder1/1.txt (not available)
+  No other repository is known to contain the file.
+failed
+git-annex: get: 1 failed
+
+
+# End of transcript or log.
+"""]]
+
+
+### Conclusion
+
+I'm so attracted to git-annex's idea, but seems it's still not robust enough to use on Windows platform - v5 direct mode repo is as far as I can get, yet it still throws away my data like this...

Added a comment: Work around
diff --git a/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment
new file mode 100644
index 0000000..fca560c
--- /dev/null
+++ b/doc/bugs/silently_failing_when_attempting_to_add_ignored_files/comment_2_9fe7fd6296db34ee8ee07fe68459e74b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="dermungo@19d0cb1f22d4169b48363cfff60c9ede2c14fffa"
+ nickname="dermungo"
+ avatar="http://cdn.libravatar.org/avatar/4f4b91e2275a6673506e2990a4f96270"
+ subject="Work around"
+ date="2017-01-13T14:54:40Z"
+ content="""
+Perhaps other people knew this already, but I thought I would post it here in case someone else has trouble finding a solution to this issue.
+
+I use a global gitignore that ignores most of the files I want to have in my annex.
+The solution was to override my global .gitignore according to this answer at SO <http://stackoverflow.com/questions/26678955/un-ignore-all-files-in-global-gitignore> by creating a .gitignore in the annexed repo with the pattern
+```
+!*
+```
+
+Now it automatically adds everything (except dotfiles) when running `git annex add $DIRPATH`.
+"""]]

Added a comment: macOS HFS+, core.precomposeUnicode
diff --git a/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment
new file mode 100644
index 0000000..ca4b9ad
--- /dev/null
+++ b/doc/bugs/Commiting_Files_Containing_Non_Ascii_Char_on_OS_X_/comment_4_8cf5dc85a94c60b9c88c8e8354f19772._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://joelpurra.com/"
+ avatar="http://cdn.libravatar.org/avatar/6b09b608da8a2f34acf3d89caf8b7438ddbd404bb2db31414855118a7dab678c"
+ subject="macOS HFS+, core.precomposeUnicode"
+ date="2017-01-13T14:27:15Z"
+ content="""
+@joeyh.name: did you notice the subtle difference between the filename in the input and the output in your example? I think it might cause problems due to a discrepancy between `git annex` and the file system when checking if a file exists or not. Not sure if the problem is in `git` or `git annex`; what do you think?
+
+```text
+git annex add George\'s\ Cafe\314\201
+...
+create mode 120000 \"George's Caf\303\251\"
+```
+
+See [Unicode Subtleties in the HFS Plus Volume Format](https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties) and `git config` for [`core.precomposeUnicode`](https://git-scm.com/docs/git-config#git-config-coreprecomposeUnicode)
+
+Here's a `printf` example.
+
+```bash
+printf '\303\251 e\314\201 (note double space)  \314\201'
+```
+```text
+é é (note double space)  ́
+```
+```bash
+printf '\303\251 e\314\201 (note double space)  \314\201' | LC_ALL=C vis -otc
+```
+```text
+\303\251 e\314\201 (note double space)  \314\201
+```
+
+"""]]

Added a comment: Any update or help needed?
diff --git a/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment b/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment
new file mode 100644
index 0000000..28842b5
--- /dev/null
+++ b/doc/todo/add_ancient_armel_build/comment_1_704f1a854e5ef62edbca60ab209d2123._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6"
+ nickname="rustikus"
+ avatar="http://cdn.libravatar.org/avatar/6fe372a7a46198829723c408af75c8cc"
+ subject="Any update or help needed?"
+ date="2017-01-12T13:40:38Z"
+ content="""
+Hi,
+
+is there any update? I do have an older version of Synology DiskStation (DS211+) which does have this CPU. Anything I can do to help?
+Disclaimer: I am quite familiar with Linux but I am no expert in programming with haskel.
+
+Thanks!
+"""]]

diff --git a/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn b/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn
new file mode 100644
index 0000000..424174a
--- /dev/null
+++ b/doc/forum/Shared_repository_without_git-annex_on_central_server.mdwn
@@ -0,0 +1,10 @@
+Hi,
+
+I went through the documentation but could not find a clear statement about central repositories (or I did not understand it).
+
+I plan to use a central server to store and sync documents from my local PC and my laptop. I do not trust this server so I want to use gcrypt to only save encrypted information remote. The server provides git and rsync access but does not have git-annex installed. My main source of information is: [fully encrypted git repositories with gcrypt](https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/). On that page is a hint that you can use a server without git-annex but I am not sure if I really understand the documentation as the [centralized git repository tutorial](https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_your_own_server/) states you need git-annex on the centralized server.
+
+Is there an option to use a centralized git repository without git-annex installed on the central server?
+
+Thank you very much and kind regards,
+Frank

Added a comment
diff --git a/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment b/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment
new file mode 100644
index 0000000..4ef9660
--- /dev/null
+++ b/doc/todo/import_--reinject/comment_7_76eba3fba57f8db0e7fd3a5832650145._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 7"
+ date="2017-01-11T22:29:55Z"
+ content="""
+Can I avoid git-annex making a copy of the file when using *reinject --known*? I have files larger than the available free space..
+"""]]

diff --git a/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn b/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn
new file mode 100644
index 0000000..4910d80
--- /dev/null
+++ b/doc/forum/Git-annex_init_gets_stuck_on_exFAT.mdwn
@@ -0,0 +1,30 @@
+I  have just started using git annex, and I cloned the annex onto an external usb formatted as exFAT. I am using Mac OS X.
+
+The clone went fine, but when running `git annex init` the following happened
+
+```
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+
+  Disabling core.symlinks.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Enabling direct mode.
+```
+then git annex appears to get stuck according to `top`:  
+
+```
+PID    COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS  
+
+86934  git-annex    0.0  01:07.09 4     0    13    4152K  0B     5684K  86933 86933 stuck    *0[1]
+```
+
+I am running git-annex 6.20170101, so direct mode should no longer be used. Is that correct? If so what should I do to figure out what's going on?
+
+ The most relevant related thread I could find was this one [Bare repo on USB ...](http://git-annex.branchable.com/forum/Bare_repo_on_USB_drive_not_providing_files/) which suggests exFAT may not work well on Linux. However, I mainly use this USB on my Macbook to supplement the SSD. Another possibly relevant thread is this one [Android table ... only exFAT...](http://git-annex.branchable.com/forum/Using_git_annex_with_Android_tablet_which_only_has_exFAT_and_no_symlinks/).
+
+I appreciate any assitance.

Added a comment
diff --git a/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment b/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment
new file mode 100644
index 0000000..959b298
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_4_6497ca72904dfdefe4e02f8a55127a8e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mdcotonopu@d25539d868f269dc6d1b838c21bb86205a40dab9"
+ nickname="mdcotonopu"
+ avatar="http://cdn.libravatar.org/avatar/7acb7ca4679a80a3ea544df55ae4959b"
+ subject="comment 4"
+ date="2017-01-11T09:35:48Z"
+ content="""
+Running high debug verbosity with DEBUG=* npm start indicates that the socket connection with the target XMPP server was started, but still the online event is never fired, and online is never logged. (The server times out at 150 seconds before anything can be logged.<a href=\"https://productriver.com/best-wireless-routers\">best 4 wireless routers</a>
+"""]]

diff --git a/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn b/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn
new file mode 100644
index 0000000..6ed716a
--- /dev/null
+++ b/doc/todo/more_efficient_memory_usage_with_git-annex_unused.mdwn
@@ -0,0 +1,3 @@
+While running *git-annex unused* on an annex with tens of thousands of items, *git-annex*'s memory usage ballooned to over 3 gigs and my PC froze. I cannot run *git-annex unused* on this annex because of this issue.
+
+If it's possible, more efficient memory management would prevent this from happening.

add describe step
diff --git a/doc/todo/reinit_should_work_without_arguments.mdwn b/doc/todo/reinit_should_work_without_arguments.mdwn
index 1c85f2a..22d3fbb 100644
--- a/doc/todo/reinit_should_work_without_arguments.mdwn
+++ b/doc/todo/reinit_should_work_without_arguments.mdwn
@@ -53,6 +53,10 @@ reflected in the tracking information:
 
     git annex fsck --fast
 
+You may also want to set a new description for the new clone:
+
+    git annex describe here "bare 2TB Seagate barracuda HD"
+
 Then, optionally, you will want to propagate that change to other
 repositories:
 

a stumbling block i found while replacing a drive
diff --git a/doc/todo/reinit_should_work_without_arguments.mdwn b/doc/todo/reinit_should_work_without_arguments.mdwn
new file mode 100644
index 0000000..1c85f2a
--- /dev/null
+++ b/doc/todo/reinit_should_work_without_arguments.mdwn
@@ -0,0 +1,61 @@
+Sometimes it may happen that you have multiple git-annex repositories
+with the same UUID. This is usually because you did something special,
+like copying a repository with `cp -a` or `dd` instead of cloning it,
+or you just replaced a drive with a fresh one. In my case, the latter
+happened: I ran out of space on my media drive and replaced it with a
+larger drive. Since it had multiple git-annex repositories (and data
+*not* managed by git-annex), I simply used `rsync` to copy the drive
+over, which created duplicate git-annex repositories with the same
+UUIDs.
+
+It may still be useful to reuse those repositories as distinct
+entities, and it is therefore important to assign new UUIDs to those
+cloned repositories so that content tracking works properly and you do
+not lose data.
+
+In this case, you actually do *not* want to specify an existing UUID
+when you run reinit: you want git-annex to generate a new one for
+you. So, in that context, I've always wondered why
+[[git-annex-reinit]] absolutely requires an argument.  I understand
+there may be *other* use cases where you may want to `reinit` a
+repository to an existing UUID, but that seems like a much *less*
+common use case, and one that may bring more trouble than is worth.
+
+So I believe there should be an easy way to assign a fresh new UUID to
+a repository. `reinit` should allow doing that when no arguments are
+given: it should show the old and new UUID and maybe a warning message
+indicating that tracking information may be wrong now if the old UUID
+is not in use anymore.
+
+As shown below, I also wonder if `reinit` should recommend the user
+perform a `fsck` to make sure the location logs reflect the change...
+
+Workaround
+----------
+
+It is obviously possible to assign a new UUID with the current
+command, by generating one by hand.
+
+Git-annex doesn't have a user-visible way of generating a new UUID, so
+we'll have to improvise something. It uses the
+[Data.UUID](https://hackage.haskell.org/package/uuid-1.3.13/docs/Data-UUID.html)
+Haskell module, in V4 mode, which is the [standard, random
+way](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.29)
+of generating UUIDs. I believe that the `uuidgen` command, when ran in
+`--random` mode, will produce similarly unique UUIDs that are good
+enough for our purpose. So I have used this to reassign new UUIDs to
+cloned copies of repositories:
+
+    git annex reinit $(uuidgen)
+
+The next step is to fix the location log so that the UUID change is
+reflected in the tracking information:
+
+    git annex fsck --fast
+
+Then, optionally, you will want to propagate that change to other
+repositories:
+
+    git annex sync
+
+Thanks for any feedback or comments... -- [[anarcat]]

diff --git a/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn
new file mode 100644
index 0000000..5d0addf
--- /dev/null
+++ b/doc/forum/Accessing_files_in_SSH_remotes_while_SSHed_into_remote.mdwn
@@ -0,0 +1 @@
+Hello, I would like to use git-annex to sync files between my desktop, laptop, and a remote server.  The remote server is part of a Beowulf cluster, these files are used to run simulations on the cluster, but I want the same files on my laptop and desktop to mirror those on the cluster.  I already have git annex assistant syncing files between the desktop and laptop.  I do not and will not ever have root access on the cluster, so I can't install git-annex there.  I can access the cluster server via ssh or by mounting it as NFS (OS X 10.11.6).  The NFS solution doesn't work due to the issues with file locking previously discussed on these forums.  I can set up an ssh repo but that's a "special remote" and I cannot access the files when ssh'ed in there, which I need to do to run the simulations.  Is there a strategy to do what I want with git-annex?  Thanks!

close
diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
index 9f09b83..baf7d43 100644
--- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
@@ -25,3 +25,6 @@ Nonetheless I'm hesitant to use it while this error occurs. Is safe to keep usin
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 I've been using git-annex for at least a year now. It's one of the greatest tools I've ever found, and is indispensable for some of my work. I can't recall any other problems I've had that weren't user-caused. So thank you!
+
+> According to yoh, this is fixed in the neurodebian build now. [[done]]
+> --[[Joey]]

update
diff --git a/doc/todo/termux_package.mdwn b/doc/todo/termux_package.mdwn
index 2914903..ac4d6b1 100644
--- a/doc/todo/termux_package.mdwn
+++ b/doc/todo/termux_package.mdwn
@@ -15,4 +15,8 @@ binary, and add it to termux's sources.list?
 > <https://github.com/termux/termux-packages/issues/420>
 > --[[Joey]] 
 
+This would also help with [[tor]] support on android, since termux has a
+tor package. And would avoid needing to bundle other 
+often out of date stuff with git-annex.apk.
+
 --[[Joey]]

update
diff --git a/doc/todo/termux_package.mdwn b/doc/todo/termux_package.mdwn
index c460fb8..2914903 100644
--- a/doc/todo/termux_package.mdwn
+++ b/doc/todo/termux_package.mdwn
@@ -6,10 +6,13 @@ Looks like termux uses ubuntu to build, but cross-compiles for android,
 using bionic. So, ghc-android would still need to be used to build
 git-annex.
 
-<https://github.com/termux/termux-packages>
+Packages: <https://github.com/termux/termux-packages>
 
 May be easier to build an appropriate .deb from the android git-annex
 binary, and add it to termux's sources.list?
 
+> Update: There's already an open issue in termux for this!
+> <https://github.com/termux/termux-packages/issues/420>
+> --[[Joey]] 
 
 --[[Joey]]

add
diff --git a/doc/todo/termux_package.mdwn b/doc/todo/termux_package.mdwn
new file mode 100644
index 0000000..c460fb8
--- /dev/null
+++ b/doc/todo/termux_package.mdwn
@@ -0,0 +1,15 @@
+Termux is an android terminal with apt. It should be possible to build
+git-annex this way, and this would be a nice alternative (or perhaps
+replacement) for the git-annex.apk.
+
+Looks like termux uses ubuntu to build, but cross-compiles for android,
+using bionic. So, ghc-android would still need to be used to build
+git-annex.
+
+<https://github.com/termux/termux-packages>
+
+May be easier to build an appropriate .deb from the android git-annex
+binary, and add it to termux's sources.list?
+
+
+--[[Joey]]

Added a comment
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment b/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment
new file mode 100644
index 0000000..ad6731a
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_4_275fcf1e6643cb247f8ed5afc4c69e56._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="fossil"
+ avatar="http://cdn.libravatar.org/avatar/951f4f4e1dca2ebe880ddb392c2d3e73"
+ subject="comment 4"
+ date="2017-01-08T15:57:42Z"
+ content="""
+This is a bug, introduced in [commit 34530e59](https://github.com/joeyh/git-annex/commit/34530e59) (release 6.20161012) and fixed in [commit b530e432](https://github.com/joeyh/git-annex/commit/b530e432) (release 6.20161031).
+
+* [git-annex chokes on filenames including spaces](https://git-annex.branchable.com/bugs/git-annex_chokes_on_filenames_including_spaces/)
+* [Single space in file name causes git annex add to fail](https://git-annex.branchable.com/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/)
+
+It happens only when the filename contains a single space, so a workaround is to first add a filename without any spaces, and then rename it:
+
+    fn=\"foo bar.txt\"; cp \"$fn\" tmp && git annex add tmp && git mv -f tmp \"$fn\"
+"""]]

Added a comment
diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment
new file mode 100644
index 0000000..340d3e3
--- /dev/null
+++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_5_9b9a369fd07cf966bdb9a44699c0d8a4._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="t.z.mates"
+ avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925"
+ subject="comment 5"
+ date="2017-01-08T06:43:48Z"
+ content="""
+So, I've done a bit more investigating, and it seems the specific command that causes the error is
+
+    git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo
+In particular, if I execute the code:
+
+    git init
+    git annex init --version=6
+    mkdir -p 1/2/3/4
+    touch 1/2/3/4/foo
+    git annex add 1/2/3/4/foo
+    git annex sync
+    git annex unlock 1/2/3/4/foo
+    echo \"bar\" >> 1/2/3/4/foo
+    cd 1/2/3/4
+    git --git-dir=../../../../.git --work-tree=../../../.. --literal-pathspecs ls-files --modified -- foo
+I get the above mentioned error. However, if I run the exact same code without any of the \"git annex\" commands (i.e. only initializing a standard git repository), the ls-files commands returns without error.
+
+I'm not sure what to make of this though; it doesn't seem to be any sort of corrupted log or bad config options (I ran the same commands on a different, working computer, copied the .git directory to the non-working computer, and still couldn't run the ls-files command). I'm rather at a loss of what to check next.
+"""]]

Added a comment
diff --git a/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment b/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment
new file mode 100644
index 0000000..e71a690
--- /dev/null
+++ b/doc/forum/Adding_the_same_content_under_different_file_names/comment_1_7c659668f62577612eaf8f463383a185._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="comment 1"
+ date="2017-01-07T15:41:36Z"
+ content="""
+You don't need to keep track of links. Just delete the links, then run:
+
+    git-annex unused
+
+This will find any content that isn't linked to. You can then run *git-annex dropunused* to free up space.
+
+See these man pages:<br/>
+<https://git-annex.branchable.com/git-annex-unused/><br/>
+<https://git-annex.branchable.com/git-annex-dropunused/>
+"""]]

diff --git a/doc/forum/Adding_the_same_content_under_different_file_names.mdwn b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
index bc0d5e8..57c3119 100644
--- a/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
+++ b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
@@ -1,4 +1,3 @@
-
 Working on the Baobáxia project, we have this interesting problem: If some content is added twice with different file names, it will appear in the git-annex repository as two symlinks pointing to the same file in the annex.
 
 So far so good.
@@ -10,5 +9,9 @@ But this means that if I want to delete a file, I have two cases:
 
 So the question is: How do I know that, apart from searching through the whole repository? Is there a more efficient way? After going through the manual I can't find it, but I may have overlooked something.
 
+Best regards and TIA for any response
+Carsten Agger
+
+
 Note: This question references bug #191 in the Baobáxia project, https://github.com/RedeMocambos/baobaxia/issues/191
 

diff --git a/doc/forum/Adding_the_same_content_under_different_file_names.mdwn b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
new file mode 100644
index 0000000..bc0d5e8
--- /dev/null
+++ b/doc/forum/Adding_the_same_content_under_different_file_names.mdwn
@@ -0,0 +1,14 @@
+
+Working on the Baobáxia project, we have this interesting problem: If some content is added twice with different file names, it will appear in the git-annex repository as two symlinks pointing to the same file in the annex.
+
+So far so good.
+
+But this means that if I want to delete a file, I have two cases:
+
+* If this content was added only once, I need to drop the binary content with git annex drop and afterwards remove the symlink with git rm.
+* If this content exists under more than one file name, I need to remove the symlink with git rm only; I should *not* drop the content.
+
+So the question is: How do I know that, apart from searching through the whole repository? Is there a more efficient way? After going through the manual I can't find it, but I may have overlooked something.
+
+Note: This question references bug #191 in the Baobáxia project, https://github.com/RedeMocambos/baobaxia/issues/191
+

diff --git a/doc/forum/Wanted_content_based_on_date_added.mdwn b/doc/forum/Wanted_content_based_on_date_added.mdwn
new file mode 100644
index 0000000..12c12e8
--- /dev/null
+++ b/doc/forum/Wanted_content_based_on_date_added.mdwn
@@ -0,0 +1,12 @@
+Hi,
+
+I was wondering whether it was possible to configure git annex in a way, that new content is held in a specific repository until it is considered old.
+
+I found that "git config annex.genmetadata true" creates year and month tags in the metadata. However, creating the wanted expression poses a problem. Afaik there is no way to access the current year/month in a wanted expression and no way to do arithmetic in a wanted expression. Furthermore, I do not know, when the assistant checks wanted expressions for matches? I assume it does so only when something changes in git or when the wanted expressions change but not in regular intervals?
+
+I guess I could whip up a cronjob that changes the wanted expression every month and do the calculations outside of git annex but this seems somehow wrong. 
+
+Is this a problem other users share or maybe have already solved?
+
+Cheers,
+Marek

Bug report: Wrong backend extension in files with multiple dots
diff --git a/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn b/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn
new file mode 100644
index 0000000..b92b32a
--- /dev/null
+++ b/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+When `git-annex add`ing files with multiple dots in them, the `SHA256E`, `MD5E` (and presumably other `*E`) backends take the extension from the second-to-last dot, instead of the last dot.
+This annoyed me because I have some photographs with names like `YYYY-mm-dd HH.MM.SS.jpg`. However, it might be intentional considering a `file.tar.gz` would have `tar.gz`.
+
+### What steps will reproduce the problem?
+[[!format sh """
+$ touch a a.b a.b.c a.b.c.d
+$ git-annex add .
+add a ok
+add a.b ok
+add a.b.c ok
+add a.b.c.d ok
+$ git-annex lookupkey *
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b.c
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.c.d
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+$ git-annex version
+git-annex version: 6.20170101+gitg93d69b1-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+NeuroDebian's `git-annex-standalone` package on Xubuntu 16.04. (Also with a Debian sid chroot with their own `git-annex 6.20161210-1`)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I'm trying to analyze and organize my huge `Photos` folder into a neat git-annex repository (with yet another [project of mine](https://www.github.com/alpernebbi/albumin)). It's a huge mess.
+
+Keep up the great work! Also thanks for fixing [my UTF-8 problem](https://git-annex.branchable.com/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/) as well. 

Added a comment: Solution
diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment
new file mode 100644
index 0000000..7978244
--- /dev/null
+++ b/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2"
+ nickname="johannes"
+ avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c"
+ subject="Solution"
+ date="2017-01-06T12:19:46Z"
+ content="""
+After the update to 20161231, I tried again. Unfortunately, I am still getting the same error.
+
+However, I noticed that removing the file for which I get the \"is outside repository\" error actually fixes the problem. Once I dropped the file from the annex as well, I was able to re-add the file without triggering this error again.
+
+Please consider this issues as fixed.
+"""]]

Added a comment: Maintain the XMPP function ?
diff --git a/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
new file mode 100644
index 0000000..ccb079e
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Apichat"
+ avatar="http://cdn.libravatar.org/avatar/af7b465d7cd067b9c5acd365bdef92ac"
+ subject="Maintain the XMPP function ?"
+ date="2017-01-05T14:00:34Z"
+ content="""
+Is it realy a good idea to remove now the XMPP function ? While XMPP is a good tool to manage social relations and is getting improve ? [As you say it is an easy way to share with friends](http://joeyh.name/blog/entry/p2p_dreams/)
+
+The lake of use of the XMPP function in Git-annex is may be due to the fact that Git-annex assistant and the XMPP feature are difficult to use on Windows - so 90% of social relations can't exist.
+
+Can't you a least maintain the XMPP function ?
+ 
+XMPP is getting improve a lot those years :
+
+  * Host services, finally we can easily use a host service up to date and with our own domain name :
+    * [[https://account.conversations.im/domain]]
+    * [[https://support-en.mailbox.org/knowledge-base/article/introduction-to-jabber]]
+    * [[https://gultsch.de/compliance_ranked.html]]
+
+  * Protocol Specifications 
+    * [The State of Mobile XMPP in 2016](https://gultsch.de/xmpp_2016.html)
+
+  * Client software :
+    * [[https://conversations.im]]
+    * [[https://jitsi.org]]
+    * [[https://conversejs.org]]
+    * [Tor Messenger](https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger)
+
+  * Server software :
+    * [[https://prosody.im]]
+    * [[https://www.ejabberd.im]]
+    * [Mongoose IM platform](https://www.erlang-solutions.com/products/mongooseim.html)
+
+
+"""]]

Added a comment: https-only access, type=S3 port=443
diff --git a/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
new file mode 100644
index 0000000..6b577d5
--- /dev/null
+++ b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mca@8789632e0b00e8efb984c948c13d9de28665f534"
+ nickname="mca"
+ avatar="http://cdn.libravatar.org/avatar/758861fe4b6231b85e761a91d6f01a2e"
+ subject="https-only access, type=S3 port=443"
+ date="2017-01-05T13:10:43Z"
+ content="""
+(My own question, answered by Use The Source Luke method)
+
+If you need to point a `type=S3` special remote at a service which provides only https (in my case, a local CEPH RADOS gateway) then you can do it by setting `port=443`.
+
+This was implemented in 6fcca2f1 and next tag was 5.20141203 .  On Ubuntu, that version is available in Xenial but not Trusty.
+
+"""]]

diff --git a/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
new file mode 100644
index 0000000..1cf693b
--- /dev/null
+++ b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
@@ -0,0 +1,3 @@
+Using the command `git-annex webapp` I was able to configure a local repository on my laptop A that is synchronized with a remote repository using ssh. This latter has sync enabled and it is encrypted. I also put it in the *full backup* group.
+
+Now, I would like to synchronize my laptop B with the remote repository with ssh. Using the webapp, I tried to do the same thing I did with my laptop A. However now, my both laptop are synchronized with the remote repository but they do not share any file between them. How can I achieve that ?

Added a comment: fresh git annex standalone was uploaded to NeuroDebian
diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment
new file mode 100644
index 0000000..28e3296
--- /dev/null
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da"
+ subject="fresh git annex standalone  was uploaded to NeuroDebian"
+ date="2017-01-03T16:03:52Z"
+ content="""
+just uploaded 6.20170101+gitg93d69b1-1~ndall+1 which was built using ghc 8.0.1-17 on stretch.  Enjoy
+"""]]

Added a comment: The `version` command reports 6.20161231-gc8eeb17da
diff --git a/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment b/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment
new file mode 100644
index 0000000..5810ccc
--- /dev/null
+++ b/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="Gioele"
+ avatar="http://cdn.libravatar.org/avatar/af2f2ba0dafe4650011d20f2168d43cff773aba97f55ae5b252bb873f391c1e2"
+ subject="The `version` command reports 6.20161231-gc8eeb17da"
+ date="2017-01-03T11:13:32Z"
+ content="""
+If I run `git-annex version` I get `6.20161231-gc8eeb17da` instead of `6.20170101-something`. Not a big deal, but maybe somebody else may be confused by it.
+
+My `git-annex` binary comes from `git-annex-standalone-amd64.tar.gz` (SHA1 `4a82bb7d0276f387e72f8e09e0d2b1f35edb49bd`).
+"""]]

diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
new file mode 100644
index 0000000..054447e
--- /dev/null
+++ b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+The new "tor onion server" setup function uses magic-wormhole to transfer the necessary keys and addresses (yay!). However it should really be using a distinct "app id". Magic-wormhole codes are scoped to a specific APPID, which means that someone using the normal CLI client (`wormhole send foo.jpg`) can get a wormhole code like "1-purple-kumquat", and someone doing a git-annex setup process can get a code like "1-green-mushroom", and they won't be competing with each other for the numeric channel-id.
+
+If magic-wormhole's file-transfer application got really popular, and there were thousands of simultaneous users, the file-transfer wormhole codes would grow to require three or four digits (e.g. "9134-purple-kumquat"), making them harder to type. But if git-annex uses a different APPID, then git-annex codes could continue to be short and easy, independent of contention for channel-ids on other applications.
+
+To tell magic-wormhole to use a different APPID, just do `wormhole --appid=$APPID send ...` or `wormhole --appid=$APPID receive ...`. APPIDs should be unique and scoped to an owner of some sort, so I'd recommend a DNS name or URL-shaped identifier, something like "git-annex.branchable.com/onion-setup". If you add a new distinct mode, one which doesn't interoperate with the current onion-setup mode, you can allocate a new APPID for that mode too (e.g. "git-annex.branchable.com/new-thing-setup").
+
+You'll have a compatibility hit when you land this: two applications using different APPIDs won't communicate, so e.g. git-annex before the patch won't do wormhole setups with git-annex after the patch.
+
+The --appid= feature was added in magic-wormhole 0.9.0, released 24-Dec-2016.
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+I haven't run git-annex's onion setup feature directly, but I'm reading through the source code from current git, cd8d905f3418b9c6a6c658a0c7256ae6f5066310, Utility/MagicWormhole.hs, and I don't see anything that adds an --appid argument. (I don't know Haskell at all, so I apologize if it's already doing --appid and I'm just not looking in the right place).
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+It looks pretty amazing! Looking forward to using it in a Dropbox-like synchronization context soon.
+
+

diff --git a/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn
new file mode 100644
index 0000000..33a8c08
--- /dev/null
+++ b/doc/forum/Import_availability_info___40__logs__47__refs__47__remotes__41___from_another_repo__63__.mdwn
@@ -0,0 +1,3 @@
+Is it possible to transfer list of remotes and their file availability information (which files are found on which remotes) from another repository?
+
+My use case would be to combine several repositories that have no copies of the actual files, but which do know of remotes that have them, so that the new composite repository would also know where to get each file.

Added a comment: Recurring?
diff --git a/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment b/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment
new file mode 100644
index 0000000..e03348a
--- /dev/null
+++ b/doc/forum/unknown_response_from_git_cat-file/comment_3_8e0458e86764242e9e35940b4db302b7._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="GregGrossmeier"
+ avatar="http://cdn.libravatar.org/avatar/66db9e436738991619a59e8ab8061e64"
+ subject="Recurring?"
+ date="2017-01-02T21:13:47Z"
+ content="""
+Still getting this myself. First I've ran into it (a few weeks ago, but I hadn't used these repos recently).
+
+	greg@x230 (git)-[master] ~/Photos % git-annex add .               
+	add 2016/10/16/2016-10-16 07.47.52.jpg git-annex: unknown response from git cat-file (\"HEAD:./2016/10/16/2016-10-16 07.47.52.jpg missing\",Ref \"HEAD:./2016/10/16/2016-10-16 07.47.52.jpg\")
+	greg@x230 (git)-[master] ~/Photos % apt-cache policy git-annex git
+	zsh: correct 'git' to '.git'? [N/y/a/e] n
+	git-annex:
+	  Installed: 6.20161012-1
+	  Candidate: 6.20161012-1
+	  Version table:
+	 *** 6.20161012-1 500
+	        500 http://httpredir.debian.org/debian testing/main amd64 Packages
+	        100 /var/lib/dpkg/status
+	     5.20141125 500
+	        500 http://httpredir.debian.org/debian stable/main amd64 Packages
+	git:
+	  Installed: 1:2.11.0-1
+	  Candidate: 1:2.11.0-1
+	  Version table:
+	 *** 1:2.11.0-1 500
+	        500 http://httpredir.debian.org/debian testing/main amd64 Packages
+	        100 /var/lib/dpkg/status
+	     1:2.1.4-2.1+deb8u2 500
+	        500 http://httpredir.debian.org/debian stable/main amd64 Packages
+	
+"""]]

update
diff --git a/doc/thanks/list b/doc/thanks/list
index 653466f..562e7cd 100644
--- a/doc/thanks/list
+++ b/doc/thanks/list
@@ -51,3 +51,7 @@ Amitai Schleier,
 Brennen Bearnes, 
 Tim Howes, 
 Willard Korfhage, 
+Shane-o, 
+Michal Sojka, 
+BonusWavePilot, 
+William Hay, 

diff --git a/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn b/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn
new file mode 100644
index 0000000..29faab8
--- /dev/null
+++ b/doc/bugs/crypto-api_is_a_global_dependency_because_of_Utility.AuthToken.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+Builds without Webapp and TestSuite fail at `Utility.AuthToken`.
+
+
+### What steps will reproduce the problem?
+
+Build git-annex with Webapp and TestSuite disabled.
+
+
+### What version of git-annex are you using? On what operating system?
+
+Version 6.20170101 on arch linux.
+
+
+### Please provide any additional information below.
+
+We need to make `crypto-api` into a global dependency. Here is a [patch](https://gist.github.com/aroig/100c2977b6df8a2109823b715647d5fb).
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh yes! I use it everyday to sync collections of binary files across computers and VM's! 
+

diff --git a/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn b/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn
new file mode 100644
index 0000000..5d8f4e5
--- /dev/null
+++ b/doc/todo/unable_to_add_files_to_a_git-annex_repo_in_Windows.mdwn
@@ -0,0 +1,13 @@
+I was trying to use the assistant, but when it didn't work I started troubleshooting. I wasn't able to get git-annex to work directly, so I'll start with it:
+
+    $ git annex add *jpg
+    add RnG.jpg
+    git-annex: .git\annex\objects\fc3\7ab\SHA256E-s63863--b26754195df2c07063401ab1dc8406a1f96c0a512724020b693e28bdbce9addf.jpg\: openTempFile: does not exist (No such file or directory)
+    failed
+    add Scan0005.jpg
+    git-annex: .git\annex\objects\3ae\9e3\SHA256E-s156803--617405c2e88c939a8cfa871a226c2fe04fe0b58b50667e4436250fcb7c59d09b.jpg\: openTempFile: does not exist (No such file or directory)
+    failed
+    (recording state in git...)
+    git-annex: add: 2 failed
+
+This is Windows 7. I've installed git 2.11 and git-annex 6.20161211-gc3ab3c6.

add news item for git-annex 6.20170101
diff --git a/doc/news/version_6.20161027.mdwn b/doc/news/version_6.20161027.mdwn
deleted file mode 100644
index 407bc98..0000000
--- a/doc/news/version_6.20161027.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-git-annex 6.20161027 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * lock, smudge: Fix edge cases where data loss could occur in v6 mode
-     when the keys database was not populated.
-   * upgrade: Handle upgrade to v6 when the repository already contains
-     v6 unlocked files whose content is already present.
-   * Improve style of offline html build of website.
-   * importfeed: Drop URL parameters from file extension.
-     Thanks, James MacMahon.
-   * Assistant, repair: Improved filtering out of git fsck lines about
-     duplicate file entries in tree objects.
-   * test: Deal with gpg-agent behavior change that broke the test suite.
-   * Improve ssh socket cleanup code to skip over the cruft that
-     NFS sometimes puts in a directory when a file is being deleted.
-   * If a transfer fails for some reason, but some data managed to be sent,
-     the transfer will be retried. (The assistant already did this.)
-   * Run ssh with ServerAliveInterval 60, so that stalled transfers will
-     be noticed within about 3 minutes.
-     (Any setting in your ~/.ssh/config or /etc/ssh/ssh\_config
-     overrides this.)"""]]
\ No newline at end of file
diff --git a/doc/news/version_6.20170101.mdwn b/doc/news/version_6.20170101.mdwn
new file mode 100644
index 0000000..1bb5de6
--- /dev/null
+++ b/doc/news/version_6.20170101.mdwn
@@ -0,0 +1,46 @@
+News for git-annex 6.20170101:
+
+   XMPP support has been removed from the assistant in this release.
+   If your repositories used XMPP to keep in sync, that will no longer
+   work, and you should enable some other remote to keep them in sync.
+   A ssh server is one way, or use the new Tor pairing feature.
+
+git-annex 6.20170101 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * XMPP support has been removed from the assistant in this release.
+     If your repositories used XMPP to keep in sync, that will no longer
+     work, and you should enable some other remote to keep them in sync.
+     A ssh server is one way, or use the new Tor pairing feature.
+   * p2p --pair makes it easy to pair repositories, over Tor, using
+     Magic Wormhole codes to find the other repository.
+     See http://git-annex.branchable.com/tips/peer\_to\_peer\_network\_with\_tor/
+   * webapp: The "Share with a friend" and "Share with your other devices"
+     pages have been changed to pair repositories using Tor and Magic Wormhole.
+   * metadata --batch: Fix bug when conflicting metadata changes were
+     made in the same batch run.
+   * Pass annex.web-options to wget and curl after other options, so that
+     eg --no-show-progress can be set by the user to disable the default
+     --show-progress.
+   * Revert ServerAliveInterval change in 6.20161111, which caused problems
+     with too many old versions of ssh and unusual ssh configurations.
+     It should have not been needed anyway since ssh is supposted to
+     have TCPKeepAlive enabled by default.
+   * Make all --batch input, as well as fromkey and registerurl stdin
+     be processed without requiring it to be in the current encoding.
+   * p2p: --link no longer takes a remote name, instead the --name
+     option can be used.
+   * Linux standalone: Improve generation of locale definition files,
+     supporting locales such as en\_GB.UTF-8.
+   * rekey --force: Incorrectly marked the new key's content as being
+     present in the local repo even when it was not.
+   * enable-tor: Put tor sockets in /var/lib/tor-annex/, rather
+     than in /etc/tor/hidden\_service/.
+   * enable-tor: No longer needs to be run as root.
+   * enable-tor: When run as a regular user, also tests a connection back to
+     the hidden service over tor.
+   * Support all common locations of the torrc file.
+   * Always use filesystem encoding for all file and handle reads and
+     writes.
+   * Fix build with directory-1.3.
+   * Debian: Suggest tor and magic-wormhole.
+   * Debian: Build webapp on armel."""]]
\ No newline at end of file

Added a comment: Issue appeared on Android 6.0 (SDK 23)
diff --git a/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment b/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment
new file mode 100644
index 0000000..0bb2b83
--- /dev/null
+++ b/doc/bugs/android__58___cannot_link_executable/comment_3_0039743728e02ca27f5346c74e8bad50._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://itorres.net/"
+ nickname="Ignacio Torres "
+ avatar="http://cdn.libravatar.org/avatar/525cc09b4eb4dc770fe20209f4a240268cad5b027135556bd27acbca9d0d3bc8"
+ subject="Issue appeared on Android 6.0 (SDK 23)"
+ date="2016-12-31T14:33:25Z"
+ content="""
+> On previous versions of Android, if your app requested the system to load a shared library with text relocations, the system displayed a warning but still allowed the library to be loaded. Beginning in this release, the system rejects this library if your app's target SDK version is 23 or higher. 
+
+Source: https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime
+
+I experience the same issue on a CM14 (Android 7) Moto X
+"""]]

Added a comment: To Reproduce
diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment
new file mode 100644
index 0000000..67d5734
--- /dev/null
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_2_792e40149bb2ae55206ebe9cea151831._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="ghen1"
+ avatar="http://cdn.libravatar.org/avatar/efd0e92b6198291138f0cd7aedbf86b6"
+ subject="To Reproduce"
+ date="2016-12-31T14:19:07Z"
+ content="""
+I've successfully reproduced the error.
+
+Steps:
+
+1. Create 5k small files using a script. (I used one given here: <https://unix.stackexchange.com/questions/199863/create-many-files-with-random-content> )
+2. Init git and git-annex
+3. Add files to git-annex. **The error occurs here** after/while (recording state in git...)
+
+If no error occurs, try increasing the number of files to 10k or more.
+
+I ran both *status* and *fsck* in both git and git-annex, with no errors, so AFAIK it hasn't corrupted anything.
+"""]]

remove old item
diff --git a/doc/todo/windows_support.mdwn b/doc/todo/windows_support.mdwn
index 78cb583..deb0e1e 100644
--- a/doc/todo/windows_support.mdwn
+++ b/doc/todo/windows_support.mdwn
@@ -28,10 +28,6 @@ Seems like this would need Windows 10.
 * gcrypt is not ported to windows (and as a shell script, may need
   to be rewritten)
 
-* Incremental fsck sets the sticky bit to record when a file is fscked,
-  and this is not done on windows, so fsck doesn't behave incrementally
-  there.
-
 * Deleting a git repository from inside the webapp fails "RemoveDirectory
   permision denied ... file is being used by another process"
 

todo
diff --git a/doc/todo/windows_support.mdwn b/doc/todo/windows_support.mdwn
index d45e9a8..78cb583 100644
--- a/doc/todo/windows_support.mdwn
+++ b/doc/todo/windows_support.mdwn
@@ -35,6 +35,8 @@ Seems like this would need Windows 10.
 * Deleting a git repository from inside the webapp fails "RemoveDirectory
   permision denied ... file is being used by another process"
 
+* Tor remotes are not supported yet. Should not be very hard to get it working.
+
 ## potential encoding problems
 
 [[bugs/Unicode_file_names_ignored_on_Windows]] is fixed, but some potential

response
diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment
new file mode 100644
index 0000000..c00a746
--- /dev/null
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_1_9b81586657226bf010145d1cd661885a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-30T22:26:10Z"
+ content="""
+This is a known bug, that is supposed to be fixed in 6.20161210.
+
+However, the fix involved upgrading the ghc compiler. I think that probably
+this has not been done in the neurodebian build yet. I will mention it to
+yoh again.
+"""]]

diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
index 445cc5e..9f09b83 100644
--- a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
@@ -10,12 +10,12 @@ Not sure. I tried creating a small test repo, adding files, and syncing, but it
 
 ### What version of git-annex are you using? On what operating system?
 
-Just updated to:
-
     git-annex version: 6.20161211+gitgc3ab3c6-1~ndall+1
 
 ... via the neurodebian repo. On Xubuntu 14.04 64x
 
+    uname -r: 3.13.0-106-generic
+
 ### Please provide any additional information below.
 
 My files appear to be okay, and otherwise the annex seems to be functioning normally.

diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
new file mode 100644
index 0000000..445cc5e
--- /dev/null
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument.mdwn
@@ -0,0 +1,27 @@
+### Please describe the problem.
+
+Received the following error upon syncing a large repo.
+
+    git-annex: unable to decommit memory: Invalid argument
+
+### What steps will reproduce the problem?
+
+Not sure. I tried creating a small test repo, adding files, and syncing, but it did not produce the error.
+
+### What version of git-annex are you using? On what operating system?
+
+Just updated to:
+
+    git-annex version: 6.20161211+gitgc3ab3c6-1~ndall+1
+
+... via the neurodebian repo. On Xubuntu 14.04 64x
+
+### Please provide any additional information below.
+
+My files appear to be okay, and otherwise the annex seems to be functioning normally.
+
+Nonetheless I'm hesitant to use it while this error occurs. Is safe to keep using my annex in spite of the error?
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I've been using git-annex for at least a year now. It's one of the greatest tools I've ever found, and is indispensable for some of my work. I can't recall any other problems I've had that weren't user-caused. So thank you!

idea
diff --git a/doc/todo/tor.mdwn b/doc/todo/tor.mdwn
index 0f5be80..3e4bc73 100644
--- a/doc/todo/tor.mdwn
+++ b/doc/todo/tor.mdwn
@@ -20,3 +20,5 @@ Eventually:
 * friend-of-a-friend peer discovery to build more interconnected networks
   of nodes
 * Discovery of nodes on same LAN, and direct connection to them.
+* Make `git annex map` show a peer's remotes?  
+  Would it be surprising if peers can learn this information?

Added a comment
diff --git a/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment b/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment
new file mode 100644
index 0000000..80075d3
--- /dev/null
+++ b/doc/todo/wishlist__58___assistant_logging_improvements/comment_1_683e2e3c94345cb6f35028cd130a4dcc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mhauru"
+ avatar="http://cdn.libravatar.org/avatar/2532433a0207ba772e6ca964e61899c0"
+ subject="comment 1"
+ date="2016-12-29T18:00:10Z"
+ content="""
+Just noticed that 1. has already been wished for here: https://git-annex.branchable.com/todo/wishlist__91__minor__93____58___add_time_stamps_to_annex_log_popups_in_webapp/
+"""]]

diff --git a/doc/todo/wishlist__58___assistant_logging_improvements.mdwn b/doc/todo/wishlist__58___assistant_logging_improvements.mdwn
new file mode 100644
index 0000000..bbc3588
--- /dev/null
+++ b/doc/todo/wishlist__58___assistant_logging_improvements.mdwn
@@ -0,0 +1,3 @@
+1. Timestamps in daemon.log would be useful.
+
+2. An easy way to get annex/assistant to periodically mail daemon.log (or even better, only the new additions to daemon.log) to the local user would be great. This would seem to me like a good use of git-annex-schedule, which at the moment only does fsck, or it could be an optional part of log rotation. With this, when running annex on a remote server, one could easily get periodic confirmations that everything's working out as it should, that fscks are not failing, etc.

devblog
diff --git a/doc/devblog/day_442__xmpp_removal.mdwn b/doc/devblog/day_442__xmpp_removal.mdwn
new file mode 100644
index 0000000..d667643
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal.mdwn
@@ -0,0 +1,15 @@
+The webapp's wormhole pairing almost worked perfectly on the first test.
+Turned out the remotedaemon was not noticing that the tor hidden service
+got enabled. After fixing that, it worked perfectly!
+
+So, I've merged that feature, and removed XMPP support from the assistant
+at the same time. If all goes well, the autobuilds will be updated soon,
+and it'll be released in time for new year's.
+
+Anyone who's been using XMPP to keep repositories in sync will need to
+either switch to Tor, or could add a remote on a ssh server to sync by
+instead. See
+<http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/>
+for the pointy-clicky way to do it, and
+<http://git-annex.branchable.com/tips/peer_to_peer_network_with_tor/> for
+the command-line way.

fix link and clarify
diff --git a/doc/tips/peer_to_peer_network_with_tor.mdwn b/doc/tips/peer_to_peer_network_with_tor.mdwn
index f825c7f..d2aa89e 100644
--- a/doc/tips/peer_to_peer_network_with_tor.mdwn
+++ b/doc/tips/peer_to_peer_network_with_tor.mdwn
@@ -23,7 +23,8 @@ to accomplish this.
 
 (The instructions below use the command line. If you or your friend would
 rather avoid using the command line, follow the
-[[share_with_a_friend_walkthrough]].)
+[[webapp_walktrough|assistant/share_with_a_friend_walkthrough]]. It's fine
+for one person to use the command line and the other to use the webapp.)
 
 In each git-annex repository, run these commands: