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

This commit is contained in:
Joey Hess 2017-10-02 11:59:30 -04:00
commit 6d20ae24dc
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 22 additions and 0 deletions

View file

@ -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).
"""]]

View file

@ -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?
"""]]