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

doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared.mdwn

@@ -0,0 +1,77 @@
+Hello,
+
+### Please describe the problem.
+I am unable to create a gcrypt remote with encryption=shared set. It allways complains with: "git-annex: cannot use gcrypt remote without encryption enabled", however the same setup works when using encryption=hybrid instead.
+
+### What steps will reproduce the problem?
+$ git annex initremote test type=gcrypt encryption=shared gitrepo=../annex-target
+
+### What version of git-annex are you using? On what operating system?
+I tried it with: 
+The Version in Debian Buster (6.20180913), latest stable and daily build.
+
+### Please provide any additional information below.
+
+Transcript:
+[[!format sh """
+
+xxx@xxx:~/Documents$ mkdir annex-test
+xxx@xxx:~/Documents$ cd annex-test/
+xxx@xxx:~/Documents/annex-test$ git init 
+Initialized empty Git repository in /home/xxx/Documents/annex-test/.git/
+xxx@xxx:~/Documents/annex-test$ git annex init test
+init test ok
+(recording state in git...)
+xxx@xxx:~/Documents/annex-test$ cd ..
+xxx@xxx:~/Documents$ git init --bare annex-target
+Initialized empty Git repository in /home/xxx/Documents/annex-target/
+xxx@xxx:~/Documents$ cd annex-test/
+xxx@xxx:~/Documents/annex-test$ touch test
+xxx@xxx:~/Documents/annex-test$ git annex add test
+add test ok
+(recording state in git...)
+xxx@xxx:~/Documents/annex-test$ git annex sync
+commit 
+[master (root-commit) 4f63e05] git-annex in test
+ 1 file changed, 1 insertion(+)
+ create mode 120000 test
+ok
+
+# This fails
+xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=shared gitrepo=../annex-target
+initremote test (encryption setup) (encryption key stored in git repository) 
+git-annex: cannot use gcrypt remote without encryption enabled
+failed
+git-annex: initremote: 1 failed
+xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=hybrid gitrepo=../annex-target keyid=30C027C6B72964DD
+
+git-annex: There is already a remote named "test"
+failed
+git-annex: initremote: 1 failed
+xxx@xxx:~/Documents/annex-test$ git remote remove test
+
+# But this works
+xxx@xxx:~/Documents/annex-test$ git annex initremote test type=gcrypt encryption=hybrid gitrepo=../annex-target keyid=30C027C6B72964DD
+initremote test (encryption setup) (to gpg keys: 30C027C6B72964DD) gcrypt: Repository not found: ../annex-target
+gcrypt: Repository not found: ../annex-target
+gcrypt: Setting up new repository
+gcrypt: Remote ID is :id:aHvfIDaNhjyLzBgYnmII
+Enumerating objects: 10, done.
+Counting objects: 100% (10/10), done.
+Compressing objects: 100% (7/7), done.
+Total 10 (delta 1), reused 0 (delta 0)
+gcrypt: Encrypting to:  -r 30C027C6B72964DD
+gcrypt: Requesting manifest signature
+To gcrypt::../annex-target
+ * [new branch]      git-annex -> git-annex
+ok
+(recording state in git...)
+xxx@xxx:~/Documents/annex-test$ 
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I think git-annex is awesome. It already helps me managing the limited diskspace on my laptop and its possibilities seem endless.
+

doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn

@@ -1,3 +1,5 @@
+Update: GitLab [removed support](https://gitlab.com/gitlab-org/gitlab-ee/issues/1648) for git-annex in 2017 with the 9.0 release.
+
 This tutorial shows how to set up a centralized repository hosted on
 GitLab. 
 

doc/todo/LFS_API_support.mdwn

@@ -0,0 +1,9 @@
+I was very disappointed to see GitLab [drop support](https://gitlab.com/gitlab-org/gitlab-ee/issues/1648) for git-annex in their 9.0 release in 2017. This makes it impossible to use GitLab to store our blobs. But there is a way out of there.
+
+GitLab, GitHub, Gogs and many other hosting providers actually support the Git LFS API for large file storage. If git-annex would support that API through (say) a special (or builtin) remote, it would be possible to transparently access those contents.
+
+I'm not talking about supporting the *client*-side LFS datastructures. Everything would stay the same from git-annex's point of view. The idea would be to allow pushing/pulling files from Git LFS repositories, quite simply.
+
+Could that work? Would it be possible to just make this into a separate remote without having to hack at git-annex's core?
+
+Thanks for your great work! :) -- [[anarcat]]

doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="status?"
+ date="2018-11-30T19:46:20Z"
+ content="""
+Why was the smudge filter improvements not accepted upstream? All I could find was [this post](https://public-inbox.org/git/xmqqwpjqdh7w.fsf@gitster.mtv.corp.google.com/) which explains it was \"discarded\" because of \"bitrot\"...
+
+Also: the third \"suboptimal\" point is that \"piping large file contents between git and filters is innefficient\". Why? Aren't there ways to efficiently pipe contents around processes? For example, pv uses the splice(2) system call instead of just read/write on the pipes... 
+
+Thanks for any details!
+"""]]