On Fri, Jul 22, 2011 at 03:01:53PM -0700, Junio C Hamano wrote: > Yes, both "just prompt you once" and "would have to be configured only > once" cut both ways, and that is mildly disturbing to my taste. > > If we annotate the remote in .git/config perhaps like this: > > [remote "foo"] > url = https://github.com/peff/foo.git > auth_context = "foo project at github" > ... > [remote "bar"] > url = https://github.com/peff/bar.git > auth_context = "bar project at github" > > and have "git push foo" pass the auth_context to the credential backend, > which can notice the two projects are in different context and cache two > identities under different contexts, would it be a good workaround for the > issue? Then, a remote that does not have auth_context configured would > use "https:github.com" that is machine-generated (in http.c in your code), > but that can easily be overridden if/as necessary. That has the minor downside of not handling one-off URLs. Actually, though, I think even with the current code, you can do better than that. The "username" is an implicit part of the context, as well. A poorly-written helper might ignore it, of course, but you can already say: [remote "foo"] url = https://peff@xxxxxxxxxx/peff/foo.git ... [remote "bar"] url = https://otheruser@xxxxxxxxxx/otheruser/foo.git"; ... The "cache" helper will match the username when looking up only a password. The "store" helper is less exacting, and uses only the opaque context. Mostly because it uses the config format as a backing store, which makes pairing usernames and passwords more difficult (but not impossible; it can be worked around by saving some context between invocations of the config callback). So that's a good reason to improve "store". As a bonus, this technique actually works to access the exact same repo as two different identities (whereas just including the path in the context does not). E.g.: [remote "repo-as-me"] url = https://me@xxxxxxxxxxx/repo.git ... [remote "repo-as-other-role"] url = https://role@xxxxxxxxxxx/repo.git ... I expect those cases to be even less common, of course, but it's nice that it's straightforward to support them. > > I tried to optimize for the common case (many repos under one identity) > > than the uncommon (many identities under one host). > > As I am not convinced if this statement is true. I admit I don't have any data beyond my own experiences. GitHub tends towards the concept of a single identity, and it has some group management. I don't know about other sites, though. Do you have any specific examples in mind? -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