Subject: Re: Dealing with corporate email recycling

From: Junio C Hamano <[email-masked]>
Date: Sat, 12 Mar 2022 16:03:35 -0800

Sean Allred <[email-masked]> 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...".