On Wed, Jul 20, 2011 at 03:17:08PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > @@ -342,11 +341,11 @@ static void http_auth_init(const char *url) > > host = at + 1; > > } > > > > + http_auth.description = url_decode_mem(host, slash - host); > > Could a hosting site like github host multiple repositories, each of which > the user may interact with under different identity? Just wondering if it > is sufficient to say "http://example.com/"; or it needs to be more > specific, e.g. "http://example.com/p/project.git/";. Yes, it's entirely possible. This is a policy decision I had to make (which I really tried to avoid in this series, but at some point, you have to make some if you don't want a million config options). It means that you can get convenient credential handling (whether it's because you've configured a username, or you're getting it from a wallet, or caching, or whatever) with: git push https://github.com/peff/git.git && git push https://github.com/peff/foo.git which should hopefully just prompt you once (and a configured username would have to be configured only once for the host). And it comes at the cost that there's not a good way to use two different identities for the same host. I tried to optimize for the common case (many repos under one identity) than the uncommon (many identities under one host). But I do wish there were a better way to say "No, I want to be more specific". In the current code, it would probably mean adding a config option to put the repo path into the unique token. If we go in the direction of dumping a list of key/value attributes to the credential helper, then it becomes up to the helper to make that policy decision. Which is extremely flexible (e.g., you could use the same identity for all repos on host1, but per-repo identities on host2). But configuring it becomes a matter of actually writing your own helper, which is not something most people would (or should have to) do. -Peff -- 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