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

doc/todo/Natively_support_s3__58____47____47___urls___40__for_addurl__44___get__44___etc__41__/comment_2_7ea1c35ce23a57fea52a593c41a8fb69._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-10-03T17:39:48Z"
+ content="""
+great question. 
+I think there is \"none\" or may be it is even incorrect to use `s3` in \"s3://\" because underlying protocol is probably http(s).
+
+I was using `s3://` because
+- that is what [s3cmd](https://s3tools.org/s3cmd) consumes and probably it was the first cmdline helper I used for interaction with S3
+- `aws` from [awscli](http://aws.amazon.com/cli/) from Amazon itself, describes `s3://mybucket/myprefix/myobject` as S3Uri; although I found no mentioning of it yet in https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html.  Here is what `aws s3 help` says
+
+```
+       S3Uri: represents the location of a S3 object, prefix, or bucket.  This
+       must  be  written in the form s3://mybucket/mykey where mybucket is the
+       specified S3 bucket, mykey is the specified S3 key.  The path  argument
+       must  begin with s3:// in order to denote that the path argument refers
+       to a S3 object. Note that prefixes are separated  by  forward  slashes.
+       For  example, if the S3 object myobject had the prefix myprefix, the S3
+       key would be myprefix/myobject, and if the object  was  in  the  bucket
+       mybucket, the S3Uri would be s3://mybucket/myprefix/myobject.
+```
+
+so it seems that in neither of those two cases there is any provisioning to specify the specific versionId (like pure http url would have), or identify the key/object by etag (somewhat volatile AFAIK, could change for the same version if recomputed).  So even if s3:// gets supported, there is no standard way to point to the particular version of the file.
+"""]]

doc/todo/config_option_to_use_all_processors_by_default.mdwn

@@ -0,0 +1 @@
+Can you add a global config flag to tell parallelizable commands to use all available cores?  Often I forget to add -JN when it would have sped things up.

doc/todo/config_setting_to_force_--progress_reporting_for_some_git_calls/comment_2_d9135802f29b78749833b7fd9967cc0b._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2018-10-03T17:55:04Z"
+ content="""
+hm...
+
+```
+$> git checkout --help | grep progress
+       --[no-]progress
+           This flag enables progress reporting even if not attached to a
+
+$> git --version
+git version 2.19.0
+```
+"""]]

doc/todo/configuration_option_for_default___34__mode__34___on_crippled_file_systems/comment_4_9367cfc5e12e43db6b53f43dc468757f._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2018-10-03T18:03:56Z"
+ content="""
+> until v6 becomes the default
+
+default only for the crippled FS or for all?
+
+Anyways, it is up to you of cause.  But even with your use-case (when to prefer direct instead of v6) it sounds like such an option would be handy so I could set it within ~/.gitconfig and have all new repos uniformly in `direct` mode (whenever v6 is the default).  Especially since `annex init` seems to have no option for getting into direct mode right away, so whenever v6 becomes default there, it would require a jump first into v6 and then running `annex direct` (if I am not missing anything).
+"""]]