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

doc/tips/largefiles/comment_13_b541d011d4c7f23227426c783a4bdc20._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Can conversion to/from annexed be made easier?"
+ date="2019-09-29T22:04:32Z"
+ content="""
+IMHO it's somewhat user-unfriendly and error-prone to have to remember a sequence of three commands to convert an unannexed file to annexed, or vice-versa.  So it would be nice if there were git-annex commands to do this in one go.
+
+In fact, I would expect `git annex add` to handle adding to the annex, and `git annex unannex` to do the opposite.  Are there good reasons why they should not be made to do that?  Even if there are, aren't those subcommands already doing very similar things?  In which case maybe the solution would be to add extra option to each to enable this behaviour?  For example `--force` or something like that in order to tell it to ignore `annex.largefiles` (although for `add` that is already used to allow adding ignored files, so we probably shouldn't conflate the two cases under one option).
+"""]]

doc/tips/largefiles/comment_14_2f8d8e73e4218b1e36e358770016cabe._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Follow-up thought"
+ date="2019-09-29T22:08:29Z"
+ content="""
+Afterthought on the immediately preceding comment - if the intention of `unannex` is to reverse `add`, then IMHO `unadd` or `undo-add` seem like more logical choices.  Renaming to one of these would free up `unannex` for the conversion use case.  But I appreciate that this is potentially confusing for users already used to `unannex`'s current behaviour, so I expect the idea will be rejected.
+"""]]

doc/tips/peer_to_peer_network_with_tor.mdwn

@@ -10,12 +10,21 @@ To use this, you need to get Tor installed and running. See
 
 	sudo apt-get install tor
 
-You also need to install [Magic Wormhole](https://github.com/warner/magic-wormhole).
+You also need to install [Magic Wormhole](https://github.com/warner/magic-wormhole) -
+here are [the installation instructions](https://magic-wormhole.readthedocs.io/en/latest/welcome.html#installation).
 
-	sudo apt-get install magic-wormhole
+*Important:*
 
-Important: You need git-annex version 6.20180705. Older versions of git-annex
-unfortunately had a bug that prevents this process from working correctly.
+* At the time of writing, you need to install Magic Wormhole under Python 2,
+  because [Tor support is only available under python2.7](https://magic-wormhole.readthedocs.io/en/latest/tor.html).
+
+* The installation process must make a `wormhole` executable available
+  somewhere on your `$PATH`.  Some distributions may only install executables
+  which reference the Python version, e.g. `wormhole-2.7`, in which case you
+  will need to manually create a symlink (and maybe file a bug with your distribution).
+
+* You need git-annex version 6.20180705. Older versions of git-annex
+  unfortunately had a bug that prevents this process from working correctly.
 
 ## pairing two repositories
 
@@ -26,7 +35,7 @@ to accomplish this.
 
 (The instructions below use the command line. If you or your friend would
 rather avoid using the command line, follow the
-[[webapp_walktrough|assistant/share_with_a_friend_walkthrough]]. It's fine
+[[webapp_walkthrough|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:
@@ -162,8 +171,8 @@ how it works.
 git-annex's Tor support uses onion address as the address of a git remote.
 You can `git pull`, push, etc with those onion addresses:
 
-	git pull tor-annnex::eeaytkuhaupbarfi.onion:4412
-	git remote add peer1 tor-annnex::eeaytkuhaupbarfi.onion:4412
+	git pull tor-annex::eeaytkuhaupbarfi.onion:4412
+	git remote add peer1 tor-annex::eeaytkuhaupbarfi.onion:4412
 
 Onion addresses are semi-public. When you add a remote, they appear in your
 `.git/config` file. For security, there's a second level of authentication
@@ -171,10 +180,10 @@ that git-annex uses to make sure that only people you want to can access
 your repository over Tor. That takes the form of a long string of numbers
 and letters, like "7f53c5b65b8957ef626fd461ceaae8056e3dbc459ae715e4".
 
-The addresses generated by `git annex peer --gen-addresses` 
+The addresses generated by `git annex p2p --gen-addresses` 
 combine the onion address with the authentication data.
 
-When you run `git annex peer --link`, it sets up a git remote using
+When you run `git annex p2p --link`, it sets up a git remote using
 the onion address, and it stashes the authentication data away in a file in
 `.git/annex/creds/`
 

doc/tips/peer_to_peer_network_with_tor/comment_5_6db70bb9266a92e249587bc4d095c472._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="branchable@bafd175a4b99afd6ed72501042e364ebd3e0c45e"
+ nickname="branchable"
+ avatar="http://cdn.libravatar.org/avatar/ae41dba34ee6000056f00793c695be75"
+ subject="Issue on openSUSE with Tor's requirement for Python 2.7 "
+ date="2019-09-29T16:41:15Z"
+ content="""
+I have updated the instructions to note two extra dependencies, the combination of which break this setup process out of the box on openSUSE.  I've filed [a bug with openSUSE](https://bugzilla.opensuse.org/show_bug.cgi?id=1152403) to improve their python-magic-wormhole package.  Hopefully I can work with the package maintainers to make this a non-issue. 
+"""]]