From e7fc0b1af1ea1c3b7f5aaf5f6a042e7a30e45a31 Mon Sep 17 00:00:00 2001 From: "80d8aa@c71d4a9510ad0353dbcf7df399c2e6bde0012474" <80d8aa@web> Date: Sat, 30 Sep 2017 17:07:39 +0000 Subject: [PATCH 1/2] Added a comment: Use existing ssh keys --- ...mment_4_8977bb8ee662c30dfcecae73cede9dfa._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment diff --git a/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment b/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment new file mode 100644 index 0000000000..696120da9c --- /dev/null +++ b/doc/forum/use_existing_ssh_keys__63__/comment_4_8977bb8ee662c30dfcecae73cede9dfa._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="80d8aa@c71d4a9510ad0353dbcf7df399c2e6bde0012474" + nickname="80d8aa" + avatar="http://cdn.libravatar.org/avatar/b3f9ee295805d0758d569ca97157fb65" + subject="Use existing ssh keys" + date="2017-09-30T17:07:39Z" + content=""" +Is there an argument against the original request of being able to use an existing *non-default* ssh key when setting up a remote ssh repo with the webapp? + +As suggested above, one could reasonably have different identities, not all of which should have access to the git-annex repo. AFAIU, the way things are one has to either use their default identity with a remote ssh repo OR temporarily enable password authentication on the server so that the webapp will generate and install its own key, then turn it off. That is a tall order and might not even be possible if the server is not under the user's control. Am I missing something? + +"""]] From ade08227c6786e7537b18bcf97a9df61b0c18794 Mon Sep 17 00:00:00 2001 From: jgoerzen Date: Mon, 2 Oct 2017 02:05:32 +0000 Subject: [PATCH 2/2] Added a comment: A hint? --- ...omment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment new file mode 100644 index 0000000000..1a2bc7cd18 --- /dev/null +++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_13_2bfa76c4083ff9c1d2a4adfe38ced2f0._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="jgoerzen" + avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4" + subject="A hint?" + date="2017-10-02T02:05:32Z" + content=""" +Hi folks, + +I no longer use git-annex so I can't comment directly on this. However, in some testing with git-remote-gcrypt, I came across an issue where changes seem to be lost. In short, every git push behaves as if --force were given. Details in [Debian but #877464](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877464). +"""]]