1

ETA: Turns out I may have the wrong end of the stick.

Collabnet SVN stores its client certificate credentials not by using ssh-agent, but with gnome-keyring (or kwallet, or other platform-specific keyrings). This, in turn, leads to a longstanding open bug in Git where it won't try to use some of the various Subversion authorization providers that are available. This is a problem all over, and I'm not even sure who would actually be responsible for getting it fixed. So for now, it's not a SO problem.


I'm using git-svn to work against a subversion repo that uses client certificate authentication over HTTPS. I've got SVN set up properly to use certs, and command-line svn always prompts for my certificate password when I do a remote operation (because I could never figure out how to have it use ssh-agent to access credentials).

Now that I'm using git-svn, remote operations (like git-svn fetch) still prompt for a password each time, but this time using an X dialog titled "OpenSSH", which is identical to the ssh-agent dialog I get when I first log on each day. So it looks like git-svn is trying to use ssh-agent (yay!) but for some reason can't get access to the one that runs at session level (boo!) and thus needs to start its own... for each invocation of git-svn.

Is there something I'm missing that lets me "point" git-svn at the running agent and thus avoid typing a password every time I want to fetch?

4

1 に答える 1

1

私が知る限り、現時点での答えは「バグ レポートを提出してください。Git が壊れています」です。

于 2011-08-16T21:21:18.360 に答える