Hi, On 3/7/09, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > == Single credentials == > > Currently if you don't save your username and password in plain-text > `.netrc` file (for HTTP transport), or avoid need for interactive > credentials using public key / private key pair (for SSH), you need to > repeat credentials many times during single git-fetch or git-clone > command. The goal is to reuse existing connections if possible, so the > whole transaction occurs using single connection and single > credentials; if that is not possible cache credentials (in secure way) > so user need to provide username and password at most once. > > '''Goal:''' git-fetch and git-clone over HTTPS and git:// > requiring providing username and password at most once > '''Language:''' C (perhaps also shell script) Perhaps you might want to look at this: http://marc.info/?l=git&m=123599968929476&w=4 At that time, I was thinking more of removing git's reliance on curl's multi interface so that it could use older versions of libcurl. But, on this point, Daniel convinced me otherwise. In fact, it doesn't make sense if you could have a up-to-date git, but not an up-to-date curl. I didn't really get a reply on my point of "minimized credential prompting", though, and I think this GSoC proposal kinda gives support to it. >From a learning standpoint, I don't think this project would be too challenging, nor can it sustain for a whole summer -- the basic strategy to allow non-curl multi usage (ie. single connections) would be to "fork" the current http slot methods and make them non-curl_multi, then finding and replacing instances of them throughout the code base. I already have a patch series that does that, plus a --persistent option for push. I'm fairly sure that it takes place on a single connection (I'm relying on my firewall log though I'm doubting it's reliability on this issue). -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
