Merge branch 'master' into no-xmpp

doc/todo/Long_Running_Filter_Process.mdwn

@@ -0,0 +1,22 @@
+Hello,
+
+while reading the release notes of git 2.11 I noticed a cool new feature has been merged:
+
+> If the filter command (a string value) is defined via
+> `filter.<driver>.process` then Git can process all blobs with a
+> single filter invocation for the entire life of a single Git
+> command.
+
+see the [git documentation][1].
+
+This has been developed in the context of git-lfs (see [PR 1382] [2]).
+
+If I understand correctly how it works this could speed up v6 repos. Looking at the history/website 
+of git-annex there doesn't seem to be yet any work on this so I though it was worth calling the 
+attention on the feature.
+
+Thanks a lot for all the work on git-annex, it's a really amazing project! The more I study it the more cool features I discover :)
+
+
+[1]: https://github.com/git/git/blob/v2.11.0/Documentation/gitattributes.txt#L384
+[2]: https://github.com/git-lfs/git-lfs/pull/1382

doc/todo/Long_Running_Filter_Process/comment_1_f155ffc7dbd074964dd53165274ec8a0._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-13T15:57:05Z"
+ content="""
+Yes, this will make [[smudge]] faster when eg checking out a lot of working
+tree changes. I will need to add support for it.
+"""]]

doc/todo/Workflow_guide/comment_4_b6f5ce361529356a77b0e6141a62c06d._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="marekj"
+ avatar="http://cdn.libravatar.org/avatar/65a60e8f5183feeeef8cef815bf73e61"
+ subject="I took the liberty to do it"
+ date="2016-12-14T07:49:26Z"
+ content="""
+I simply copied @xloem's into a new [[workflow]] page. I have been looking for such a guide myself for quite some time.
+"""]]

doc/todo/Workflow_guide/comment_5_6ec6fb45021ba82ed6a4bb9a6f3cfceb._comment

@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-12-20T19:04:12Z"
+ content="""
+Good start on the workflow page!
+
+I've added some links to it to make it discoverable.
+
+Not sure if the workflow page quite gets to what was originally requested:
+
+> I want to start keeping track of some files I have in a directory
+> I want to copy them to a second computer.
+> From a third place, I want to get them from the second computer.
+> I change the files on one computer, and I want to make sure the changes get synced to the others.
+> What are the commands you'd run at each step?
+
+Leaving this todo open for now..
+"""]]

doc/todo/Workflow_guide/comment_6_640e5c6cdea8a6fae63c3fab6970f1f2._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-12-21T18:19:07Z"
+ content="""
+In a way the use cases on the front page of the website are trying to
+accomplish the same thing requested here. I think that section could be
+moved more in the direction of listing some ways to use git-annex and
+linking to walkthroughs for the different use cases.
+"""]]

doc/todo/renameremote.mdwn

@@ -0,0 +1,24 @@
+Sometimes a name has been used for a special remote, and you want to change
+the name. A common reason is that the special remote has become dead, and
+you want to reuse the name for a new special remote. 
+
+Initremote prevents reusing a name when the old one exists, even if the old
+one is dead. And that makes sense in general, because a dead remote can
+come back sometimes, and that would leave the repo with two special remotes
+with the same name, and so enableremote would need to be run with a uuid
+instead of a name to specify which one to enable, which is not a desirable
+state of affairs.
+
+So, add `git annex renameremote oldname newname`. This could also do a `git
+remote rename`, or equivilant. (`git remote rename` gets confused by special
+remotes not having a fetch url and fails; this can be worked around by
+manually renaming the stanza in git config.)
+
+Implementing that would need a way to remove the old name from remote.log.
+We can't remove lines from union merged files, but what we could do is
+add a new line like:
+
+	- name=oldname timestamp=<latest>
+
+And in parsing remote.log, if the UUID is "-", don't include the
+remote with that name in the the resulting map.

doc/todo/smudge.mdwn

@@ -37,6 +37,10 @@ git-annex should use smudge/clean filters.
   And developed a patch set:
   <http://thread.gmane.org/gmane.comp.version-control.git/297475>
 
+* Implement git's new `filter.<driver>.process` interface, which will
+  let only 1 git-annex process be started by git when processing
+  multiple files, and so should be faster.
+
 * Checking out a different branch causes git to smudge all changed files,
   and write their content. This does not honor annex.thin. A warning
   message is printed in this case.  

doc/todo/tor.mdwn

@@ -0,0 +1,23 @@
+git-annex sync over tor
+
+Mostly working!
+
+Current todo list:
+
+* Webapp UI to set it up.
+* When a transfer can't be done because another transfer of the same 
+  object is already in progress, the message about this is output by the
+  remotedaemon --debug, but not forwarded to the peer, which shows
+  "Connection reset by peer"
+* Think about locking some more. What happens if the connection to the peer
+  is dropped while we think we're locking content there from being dropped?
+
+Eventually:
+
+* Windows and Android support.
+* Limiting authtokens to read-only access.
+* Revoking authtokens. (This and read-only need a name associated with an
+  authtoken, so the user can adjust its configuration after creating it.)
+* friend-of-a-friend peer discovery to build more interconnected networks
+  of nodes
+* Discovery of nodes on same LAN, and direct connection to them.

doc/todo/xmpp_removal.mdwn

@@ -21,6 +21,8 @@ telehash. But, can't wait on that forever..
 XMPP support is already disabled by default in some builds of git-annex,
 notably the stack build. It's never worked on Windows.
 
+The [[no-xmpp]] branch is ready for merging.
+
 Next step is probably to default the flag to false by default,
 except for in a few builds like the Debian package and standalone builds.