From 84e0ea5ce3488db4460121f1901bd61c7ec6262c Mon Sep 17 00:00:00 2001 From: anarcat Date: Fri, 30 Nov 2018 19:46:20 +0000 Subject: [PATCH 1/4] Added a comment: status? --- ...mment_1_b41830b59c47ce5041c6005d41baf550._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment b/doc/todo/git_smudge_clean_interface_suboptiomal/comment_1_b41830b59c47ce5041c6005d41baf550._comment new file mode 100644 index 0000000000..6cd48a9831 --- /dev/null +++ b/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! +"""]] From 1079b5b2964baffb12d454d7cf546604ce03f0f6 Mon Sep 17 00:00:00 2001 From: "lukasstraub2@bbbb2ef261a0994edda5f5f55999dfac5998d4e5" Date: Fri, 30 Nov 2018 20:51:48 +0000 Subject: [PATCH 2/4] --- ...pt_Remote_with_encryption__61__shared.mdwn | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared.mdwn diff --git a/doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared.mdwn b/doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared.mdwn new file mode 100644 index 0000000000..32528a8c09 --- /dev/null +++ b/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. + From f5ec2f074df3e52505ad8e30dd6d02a90113ee5f Mon Sep 17 00:00:00 2001 From: anarcat Date: Fri, 30 Nov 2018 21:27:03 +0000 Subject: [PATCH 3/4] note git-annex not supported by gitlab anymore --- doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn b/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn index 2f4a0765ca..e0aa5a9b78 100644 --- a/doc/tips/centralized_git_repository_tutorial/on_GitLab.mdwn +++ b/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. From e2fd1a513a9a07130d55c964fdc68eefc2c4a629 Mon Sep 17 00:00:00 2001 From: anarcat Date: Fri, 30 Nov 2018 21:30:22 +0000 Subject: [PATCH 4/4] feature request: LFS API support! --- doc/todo/LFS_API_support.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/todo/LFS_API_support.mdwn diff --git a/doc/todo/LFS_API_support.mdwn b/doc/todo/LFS_API_support.mdwn new file mode 100644 index 0000000000..20773787cf --- /dev/null +++ b/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]]