Sean Allred <allred.sean@xxxxxxxxx> writes:
> As a baseline, we know the following statements are true:
>
> 1. A person's preferred name can change at any time.
> 2. A person's preferred email can change at any time.
> 3. Neither of these pieces of information are necessarily
> identifying in a given codebase.
Another thing we know is
4. People know that old e-mail addresses stay in archives and
address books of people, and find it wise to avoid reusing an
address somebody else (especially well-known ones) has been
using, so that they do not get e-mails from total strangers
and having to tell them that the intended recipient does not
read the mailbox anymore.
> 1. Do nothing. Leave it to the developer to determine the correct
> contact information without assistance.
>
> This doesn't really resolve the confusion, but it is technically
> an option.
>
> 2. Use gitmailmap(5) functionality to resolve historical emails to
> primary emails.
>
> Sadly this doesn't actually solve the email recycling problem.
> Since one email could be used by multiple developers, there's no
> way (that I can see) to use a single mailmap file to resolve one
> of these emails to a single person.
GNU arch (tla) had an interesting idea around this area and used
combination of time and e-mail address to identify a person.
one@corp--$date referred to the person who had control of the
address on the specified date, where $date can be abbreviated to
2022 or 202201 to mean 20220101.
The mailmap allows "Name e-mail" or "e-mail" to be mapped to
canonical "Name e-mail", but we should be able to coax "valid time
range" information encoded in each entry of the .mailmap format,
i.e. "if you see 'Name e-mail' between time X and Y, map that to...".
