From: Jeff King <peff@peff.net>
Date: Fri, 22 Jul 2011 22:13:38 GMT
Subject: Re: [PATCH 10/14] http: use hostname in credential description
Message-ID: <20110722221337.GA15753@sigill.intra.peff.net>
In-Reply-To: <7vbowmx9da.fsf@alter.siamese.dyndns.org>

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@github.com/peff/foo.git
    ...
  [remote "bar"]
    url = https://otheruser@github.com/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@example.com/repo.git
    ...
  [remote "repo-as-other-role"]
    url = https://role@example.com/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