Re: [PATCH] gpg-interface: Look up signing keys with only email address

> > Sometimes gpg signing key UIDs include a comment between the name and
> > parenthesis in the form of:
> >
> >   John Smith (example) jsmith@example.com
> >
> > There's no way for git to find signing keys associated with just these
> > UIDs, so look up a partial match on the email only.
> 
> This codepath is about finding the key for the current user who is
> in control of what committer is found by the git_committer_info()
> call, no?  It is not like we are finding the key that corresponds to
> a random name and e-mail address on "From:" line, right?
> 
> Assuming that it is the case, it is unclear where the claim "There's
> no way for git to find" comes from.  It isn't a statement that is so
> obviously true, at least to me, without some explanation.

> > -	return git_committer_info(IDENT_STRICT | IDENT_NO_DATE);
> > +	return git_committer_info(IDENT_NO_NAME | IDENT_STRICT | IDENT_NO_DATE);
> 
> With this change, those who use more than one identities associated
> with the same e-mail address, but different human-readable names,
> will get their workflow broken, won't they?
> 
> They may be using "Will <a@dd.re.ss>" when they work on a project,
> while using "Bill <a@dd.re.ss>" for another project, configured via
> their .git/config in the repositories used for these two projects.
> And each name+address combination they have may map to a distinct
> GPG key, used to sign for each project.  With this change, since the
> call no longer returns the name they were using to differentiate the
> two keys, one of the projects they manage would lose out, no?

> So, I am not convinced that the patch is trying to address the right
> problem, and I have a mild suspicion that the proposed solution to
> tweak NO_NAME may simply be robbing Peter to pay Paul.  If you have
> named your GPG key in your keyring with a name-email pair that is
> different from how you configured your committer identity, the right
> solution for such a case already exists in the form of user.signingkey
> configuration variable already.