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

doc/bugs/Assistant_dropping_files_it_has_just_transferred_elsewhere_again.mdwn

@@ -0,0 +1,23 @@
+Setup:
+
+* fresh install of Debian Wheezy on machines A & B, git-annex 4.20130227 pulled in from unstable
+* clone repository onto A & B and pair them (manual SSH key setup), and plug USB backup drive, U, into A
+* U has repository group `backup` and preferred content string `standard`
+* A & B have repository group `client` and preferred content string `present or include=subdir1/* or ...`
+
+Steps:
+
+* Add a new file to B
+* On B, `git annex copy -t A newfile`
+
+Expected:
+
+* File arrives at B and is copied to U by B's assistant
+* File remains on B
+
+Actual:
+
+* File arrives on B and is copied to U
+* File is dropped from B
+
+Seems like a resurfacing of [[forum/assistant_overzealously_moving_stuff_to_other_repos]]?  Thanks.

doc/bugs/Assistant_dropping_from_backup_repo.mdwn

@@ -0,0 +1,23 @@
+Setup:
+
+* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable
+
+Steps:
+
+* clone existing repository and activate assistant
+* Have USB drive, U, with repository group `backup` and preferred content string `standard`
+
+Expected:
+
+* Assistant never ever tries to drop anything from U
+
+Actual:
+
+* Assistant immediately tries to drop files from U; fortunately I didn't have the USB drive plugged in
+* Changing the preferred content string of U to `present or include=*` stops the dropping, but this was never required before
+
+Additional information:
+
+* The files that the Assistant started trying to drop were, I believe, the first (alphabetically) files in my repository to contain non-ascii characters in their file names (some French accented letters)
+
+Thanks.

doc/bugs/Partial_direct__47__indirect_repo.mdwn

@@ -0,0 +1,22 @@
+Setup:
+
+* Fresh install of Debian Wheezy on machines A & B, git-annex 4.20130227 pulled in from unstable
+* On both machines, clone old repository which contains both annexed files and a three small files checked straight into git
+
+Steps:
+
+* On both machines, use webapp to create `~/.config/git-annex/autostart` by just firing it up and typing in location of existing repository
+* Move a new file into B's annex, in a subdirectory that is preferred on both A & B
+
+Expected:
+
+* The new file is copied over to A and everything remains in indirect mode
+* Three files checked straight into git remain checked straight into git (see below for why this is a variant on [[bugs/Switching_between_direct_and_indirect_stomps_on___39__regular__39___git_files/]])
+
+Actual:
+
+* New file copied over but seems to be in direct mode, while all the other content that is present is still symlinked
+* Files checked into git converted to direct mode files too (can tell this has happened by following step:)
+* Typing `git annex indirect` on A & B shows conversion of precisely four files (three files originally checked into git and new file added to B ) back to indirect
+
+Thanks.

doc/bugs/Renamed_special_remote_cannot_be_reactivated_by_the_webapp.mdwn

@@ -0,0 +1,28 @@
+Setup:
+
+* fresh install of Debian Wheezy with git-annex 4.20130227 pulled in from unstable
+* clone existing repository and activate assistant
+* repository has encrypted rsync remote originally setup with the name `metaarray`
+* this remote was renamed to `ma` a long time ago, using the webapp
+* had to perform this rename on each client
+
+Steps:
+
+* attempt to reactivate special remote using webapp repositories page, on reinstalled machine
+
+Expected:
+
+* special remote starts working
+* renaming special remotes ought to survive clones
+
+Actual:
+
+* firstly, special remote activation page has blank hostname box and the hostname of the machine is in the username box
+* form gives error "cannot change encryption type of existing remote"
+
+Workaround:
+
+* execute `git annex initremote metaarray`
+* rename `metaarray` to `ma` again using the webapp
+
+Perhaps the renaming of the remote not surviving clones is unavoidable, but the webapp should be able to cope with the situation.  Thanks.

doc/forum/git-remote-gcrypt/comment_2_fdcaf507e14c995636dd93a41e488df3._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 2"
+ date="2013-03-12T09:33:17Z"
+ content="""
+The use case this is really good for, that XMPP push can't help with, is for when two paired machines are almost never both turned on at once.
+"""]]

doc/forum/preferred_content_settings_for_multiple_symlinks/comment_2_ccea74d8b5a4de1f3cd1f6da6694ae0e._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ ip="82.36.235.9"
+ subject="comment 2"
+ date="2013-03-12T09:34:08Z"
+ content="""
+Thanks for the tip--I will definitely make another attempt at some point.
+"""]]

doc/walkthrough/using_ssh_remotes/comment_11_f2775a151ed50caba27057bd9c38bae2._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawniXLhO9mLn-7EDfawdENZ2fQwlGy5w_oc"
+ nickname="Michał"
+ subject="unrecognized command"
+ date="2013-03-12T06:32:56Z"
+ content="""
+Thanks Matthias, I fought with this as well, this was the tip I needed to move on.  I'm using the Linux standalone, and I had 2 issues getting everything to work without getting git-annex-shell errors.
+
+1. The autoinstalled wrapper could not be found, I had to comment the \"Ubuntu exit\" line and add the $HOME/.ssh to path to get rid of \"command not found\"
+2. Had to modify the wrapper by replacing the \"$SSH_ORIGINAL_COMMAND\" by \"$@\" to get rid of \"fatal: unrecognized command ''\"
+
+
+"""]]