RE: Dealing with corporate email recycling

>On 2022-03-12 at 22:38:56, Sean Allred wrote:
>> * Proposal: UUIDs
>>
>> To get what we want (i.e., the ability to run `git show HEAD~1`, know
>> that Ada wrote it, and report her current contact information), we
>> need some way of tracking identity over time.  A naive solution could
>> be to extend the mailmap format as recognized by Git:
>>
>>     $ git cat-file blob HEAD~1:.mailmap
>>     A. U. Thor <foo@example.com> [uuid A] <ada@example.com>
>>
>>     $ git cat-file blob HEAD:.mailmap
>>     A. U. Thor <ada@example.com> [uuid A]
>>     Roy G. Biv <foo@example.com> [uuid B] <roy@example.com>
>>
>> Now, when I run `git show HEAD~1`, Git would determine the UUID of the
>> email on the commit using the mailmap version in that tree:
>>
>>     $ git -c mailmap.blob=HEAD~1:.mailmap check-mailmap --uuid
>"<foo@example.com>"
>>     A
>>
>> Then, we can use that UUID to resolve to the current contact information:
>>
>>     $ git check-mailmap --uuid=A
>>     A. U. Thor <ada@example.com>
>>
>> Mailmap-sensitive commands can use this logic internally -- possibly
>> guarded under some new config setting.
>
>It's my intention to implement an approach where people's emails are identified
>by a key fingerprint of some sort and then converted into the proper email
>address by a mailmap that lives outside of the main history.  That is, my email
>address might be
>ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad@ssh-
>sha256.ns.git-scm.com,
>and then we have a mailmap that converts between the two.  If you wanted to
>have a UUID-based one, you could do 77c747a3-1599-4c8c-9569-
>f729c17632e6@uuid.ns.git-scm.com (assuming that namespace were registered).
>
>The benefit to the key part is that you can essentially prove that you are who you
>say you are.  A UUID doesn't have the possibility.
>
>This was discussed briefly at some sort of contributor summit we had at some
>point, but I've been busy and haven't gotten to it yet.  It is on my list of projects,
>however.