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@xxxxxxxxxxx> [uuid A] <ada@xxxxxxxxxxx> > > $ git cat-file blob HEAD:.mailmap > A. U. Thor <ada@xxxxxxxxxxx> [uuid A] > Roy G. Biv <foo@xxxxxxxxxxx> [uuid B] <roy@xxxxxxxxxxx> > > 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@xxxxxxxxxxx>" > A > > Then, we can use that UUID to resolve to the current contact information: > > $ git check-mailmap --uuid=A > A. U. Thor <ada@xxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxxxx, 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@xxxxxxxxxxxxxxxxxxx (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. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
