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

doc/bugs/dotfiles_handled_differently.mdwn

@@ -0,0 +1,32 @@
+For most files, whether they get annexed is controlled by `annex.largefiles`.  But dotfiles are configured to *never* be annexed regardless of `annex.largefiles`.  This is unexpected and confusing.  More oddly, `git-annex-add` doesn't seem to add them to regular git, either.
+
+I'm guessing this flows from the new default of `git add` adding files to the annex, which [[I hope gets reversed|forum/lets_discuss_git_add_behavior]].  But separately, I'm not sure why `git-annex-add` does not add the dotfiles to regular git:
+
+[[!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
+
+(master_env_v163_py36) 22:32  [newtree02] $ git status
+On branch newtree02
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+        mydir/
+
+nothing added to commit but untracked files present (use "git add" to track)
+(master_env_v163_py36) 22:32  [newtree02] $ ls -al mydir
+total 12
+drwxrwxr-x 2 ilya ilya 4096 Oct 20 22:31 .
+drwxrwxr-x 3 ilya ilya 4096 Oct 20 22:31 ..
+-rw-rw-r-- 1 ilya ilya    9 Oct 20 22:31 .mynewdot
+(master_env_v163_py36) 22:32  [newtree02] $ git annex add mydir
+(master_env_v163_py36) 22:32  [newtree02] $ git status
+On branch newtree02
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+        mydir/
+
+
+# End of transcript or log.
+"""]]

doc/forum/Sending_requests_across_the_network/comment_4_b228914d2a3d7838ebc8f1cae4d8b59a._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="a case for request routing"
+ date="2019-10-20T19:42:03Z"
+ content="""
+This could also be what you're after (just a design)? https://git-annex.branchable.com/design/requests_routing/
+
+This is something I would love to see implemented too. Especially as an addition to get / drop / fsck commands.
+"""]]

doc/forum/Sending_requests_across_the_network/comment_5_3dba5baa95b43f542fe3737397b8c7a8._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 5"
+ date="2019-10-21T02:02:31Z"
+ content="""
+Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
+"""]]

doc/forum/Sending_requests_across_the_network/comment_6_6ef44abc1c279abf315b949d2f947fa4._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2019-10-21T02:02:47Z"
+ content="""
+Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
+"""]]

doc/forum/git-annex_tor_remote_not_working.mdwn

@@ -0,0 +1,15 @@
+So i wanted to try local pairing for a while, but since i wanted to sync between local host and a remote server (which is heavily secured, firewall, block port except one available for ssh etc).
+Although, i could have used the ssh remote, but i couldn't found a flag to specify a private key file (might need to search more), since i'm using a separate private key + password to ssh into the remote server.
+
+Anyway, tor installed fine on both host and server, but even though tor was working fine by itself (tried it using sock5 and curl to test), git-annex couldn't initialize it, and was stuck on `Unable to connect to hidden service. It may not yet have propigated to the Tor network. (SocksErrorHostUnreachable) Will retry..` when using `git annex enable-tor` 
+I tried it on the assistant too with the same error in the logs.
+
+I'm using default setting on the torrc, I'm on ubuntu 19.04 x86_64 using 7.20190129 version of git-annex.
+
+P.S:I used this one liner to test if tor was working ` curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs`, not sure if there better way/other to test it.
+
+EDIT: I updated the git-annex version on both the host and server, as i only now noticed they were old (and also since i tried a lot of other things and that was the last thing that could work).
+Using 7.20190819+git2-g908476a9b-1~ndall+1 from neuron's repo.
+Still not working and now stuck at `git-annex: tor failed to create hidden service, perhaps the tor service is not running` when doing `sudo git-annex enable-tor $(id -u)`
+(and yes, the tor service is indeed running, which make that weird)
+Obvious, but i also made sure to restart both tor and git-annex before and after upgrading in my consecutive attempts.

doc/forum/lets_discuss_git_add_behavior/comment_19_c1d6b7ae3b7cc0f7f0dc8d55cf629508._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="different handling of  dotfiles"
+ date="2019-10-21T02:51:16Z"
+ content="""
+Related: [[bugs/dotfiles_handled_differently]]
+
+For most files, whether they get annexed is controlled by `annex.largefiles`. But dotfiles are configured to never be annexed regardless of `annex.largefiles`. This special-casing (in `.git/info/attributes`) is unexpected and confusing.  It is probably a consequence of making `git add` annex files by default, but it's better to change that default than to have the special case.  Also, `git-annex-add` seems to ignore the dotfiles, as in the bug report above.
+
+I thought of reverting to an earlier version of git-annex until these and other issues can get worked out, but realized I can't, since the repos got irreversibly auto-upgraded to v7...
+"""]]

doc/tips/finding_which_file_matches_a_key.mdwn

@@ -0,0 +1,14 @@
+I have a music file which makes my music player unhappy. unfortunately, it (the music player) only shows me the target of the symlink, the "key" of the file, e.g. `SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3`. There's a way to find which remotes have that key:
+
+    $ git annex whereis --key=SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3
+    whereis SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3 (7 copies) 
+      	059b8bdb-2716-4ac9-b06e-9b1176af361d -- anarcat@curie:~/mp3 [here]
+    ok
+
+But that doesn't show me which file(s) actually point to it. [[git-annex-list]] and [[git-annex-find]] don't have the `--key` parameter and [[git-annex-matching-options]] doesn't have it either, so it makes it difficult to find which file points to that key.
+
+The only way I found to do this was to use the `find` command, like this:
+
+    find -lname '*SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3'
+
+I would love to have a way to use `git-annex`'s knowledge of its own repo here instead... Could this be improved? --[[anarcat]]