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

doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~helpunclejackoff"
+ nickname="helpunclejackoff"
+ avatar="http://cdn.libravatar.org/avatar/5a03d3e717ff477309d5b5f5726fcd3b51bb5c6b2241e796f93bd4f340426d04"
+ subject="Dumb old me...."
+ date="2016-10-15T10:12:17Z"
+ content="""
+In my script I was using `git add` instead of `git annex add`...
+
+All is good now.
+
+Cheers!
+"""]]

doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn

@@ -0,0 +1,32 @@
+### Please describe the problem.
+
+Originally spotted/reported: https://github.com/datalad/datalad/issues/1020
+
+If that is mandatory, then I guess there should be some error message.
+
+### What steps will reproduce the problem?
+
+create a remote repo without specifying version, i.e. of version 5 and copy data into it
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160923+gitgd1dabb3-1~ndall+1
+
+### Please provide any additional information below.
+
+Output from running http://www.onerussian.com/tmp/v6-push.sh  with argument which specifies annex version within remote 
+
+[[!format sh """
+
+$> ./v6-push.sh 5 2>&1 | grep '>>>' 
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+
+$> ./v6-push.sh 6 2>&1 | grep '>>>' 
+>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat
+>>> 123
+
+"""]]
+
+
+[[!meta author=yoh]]

doc/devblog/day_420__delayed_debugging.mdwn

@@ -7,7 +7,7 @@ Finally got back to that today. Luckily, I *was* able to reproduce the bug
 using felix's repo. The bug only occurs when there's a change deep in a
 tree of an adjusted branch, and not always then. After staring at it for a
 couple of hours, I finally found the problem; a modification flag was not
-getting propigated in this case, and some changes made deep in the tree
+getting propagated in this case, and some changes made deep in the tree
 were not getting included into parent trees.
 
 So, I think I've fixed it, but need to look at it some more to be sure, and

doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn

@@ -0,0 +1,9 @@
+I am using the git annex assistant between two linux machines. Sometimes, it seems to "lose" a file, having a dangling symlink of it. Fsck shows that there are no known copies of the file in the repositories, but if I do a search in .git/annex/objects, I'm able to find the file.
+
+
+I'm using git annex 6.20160923+gitgd1dabb3-1~ndall+1 and direct mode repositories thanks to the assistant.
+
+Any advice would be highly appreciated. Right now, I can't get it to consistently do this behavior, but any help would be appreciated, including what I should post, look for, etc. for more troubleshooting.
+
+Thanks again,
+Ryan

doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment

@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="git-annex-undo removes files, possibly destroying information? Please explain."
+ date="2016-10-14T07:02:42Z"
+ content="""
+Hello,
+
+## Context
+
+Thank you for git-annex. I'm progressing in learning how to use it. Seems to work as intended with only annexed files.
+
+I actually need mixed content repository and like the idea of `annex.largefiles` deciding which files go into the annex.
+
+While experimenting with mixed content repository, I had `git-annex-undo` destroy information twice.  Or perhaps I did something wrong?
+
+## What happened
+
+Here's my .gitattributes
+
+```
+*.NEF annex.largefiles=anything
+*.JPG annex.largefiles=anything
+*.jpg annex.largefiles=anything
+
+```
+
+I had a directory (say, `newdir`) with some jpg and some other files, not known by git or git-annex so far.
+
+Based on [https://git-annex.branchable.com/tips/largefiles/](https://git-annex.branchable.com/tips/largefiles/) I expected both `git add` and `git annex add` to add NEF JPG jpg to the annex, and other files as regular git files.  
+
+In case of problem, I expected `git annex undo` to revert state to the one just before the last command (which is: full of my regular files, not symlinks or empty).
+
+* `git add newdir` added them *all* as *regular* files, not partly in the annex as expected.  Surprised, I wanted to undo and try another command.
+* `git annex undo` emptied `newdir` completely. Wow! Fortunately these were copies, else they would have been gone forever! To be fair I have not checked at that point if files had been copied in annex, which as only copy would still be a mess because file names would have been lost anyway. 
+
+I used `git reset <hash>` to revert state git-style, checked with `git status` that state was indeed back to pre-add (newdir empty, not known to git), then copied the files again from their source.
+
+* `git annex add newdir` added them all as *annexed* files, replacing with links, not partly as regular files as expected.
+* `git annex undo` emptied `newdir` completely. I expected my regular files back in place. 
+
+I had the intended result by using `git add` on regular files and `git annex add` to add files to be annexed.  As if `.gitattributes` were absent.
+
+git-annex compiled on Debian unstable as of 2016-10-13 from git source, commit 3135d35094aa5453ef7a5f12762e00e0139a6dbb.
+
+## Questions
+
+* Have I explained situation clearly?
+* Did `git annex add` behave as intended by you? Wasn't it supposed to automatically decide which files go to the annex?
+* Did `git annex undo` behave as intended by you? Wasn't it supposed to revert working directory to the state just before the wrong \"add\"?
+* Have I used `.gitattributes`, `add` commands correctly?
+
+Thank you.
+"""]]

doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="comment 2"
+ date="2016-10-14T07:23:51Z"
+ content="""
+Adding this to `.gitattributes`:
+
+```
+*.xmp annex.largefiles=nothing
+```
+
+Causes `git-annex add` to behave as expected.  Questions about `git annex undo` behavior remain.
+
+"""]]

doc/todo/unlock_--read-only.mdwn

@@ -0,0 +1,3 @@
+"annex unlock" in thin mode of v6 hard-links key into the file location and makes it RW.  This is obviously for the case where modifications to the file need to be done and danger is understood. In my case, I need unlock to avoid having symlinks in the files since some software doesn't digest them well (might copy without dereferencing or dereference and look for neighboring files in the directory), and I want to use unlock to pretty much provide "symlink-free" view of the tree BUT at least with some protection, which could be given if files are unlocked read-only, so no inplace modifications could happen without explicit change of the permissions.
+
+[[!meta author=yoh]]