Re: PATCH: Less fragile lookup of gpg key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Grant Olson <kgo@xxxxxxxxxxxxxxx> writes:

> On 5/1/2010 1:18 PM, Junio C Hamano wrote:
>> A Large Angry SCM <gitzilla@xxxxxxxxx> writes:
>>>
>>> Why not fall back to just the email if the full lookup fails?
>> 
>> Thanks; I like that suggestion a lot better.  Grant's suggestion does not
>> make the lookup "less fragile", but actually makes it less reliable for
>> people with the same address with different spellings of name and want to
>> choose which one to use per project.
>> --
>> 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
>
> Unless I'm mis-understanding you, the does the opposite of that.  It
> finds your gpg key based on your git email, ignoring your git name, so
> that different spellings of the name between gpg and git become irrelevant.

If I have two keys like these:

    Junio C Hamano <gitster@xxxxxxxxx>
    Junio Hamano <gitster@xxxxxxxxx>

and I have the latter set in .git/config to use for the project I am
working on, your patch picks one at random, making the process less
reliable.

AFAIU, ALASCM's suggestion was to first try the current method (which
reliably picks what I told git to use by specifying user.name), and only
if that fails, i.e. if I do not have neither of the above two keys but
only have a key named like e.g.

    Git Panda <gitster@xxxxxxxxx>

then use only the e-mail as you wanted to, but do so purely as a
fallback.

Which I found quite reasonable.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]