Re: Dealing with corporate email recycling

(CC others who have been involved in the conversation; I started a separate thread off the original post since this takes an entirely separate direction.)

I wanted to provide a possible approach for other organizations that may run into this issue in the future. If you have the opportunity that we do in rewriting history, we found a nice workaround by way of 'unique-ifying' the email address using the '+' syntax supported by most email providers -- notably for us, we tested that it does work with Exchange.

As I went through previously, the problem is that our organization recycles emails like <Sean@corp.net>. If the owner of <Sean@corp.net> leaves, I have the opportunity to take ownership of <Sean@corp.net> after a waiting period. This presents the core problem: <Sean@corp.net> could be two different people at two different points in time.

Our first approach to solving this problem was to collaborate with our internal IT folks to see if we could additionally generate a totally unique email address based on that employee's ID. For various reasons with which I'm not familiar enough to elaborate, this wasn't really possible -- we could not be provided a totally static email address for any given person. After bouncing the problem around internally for a while, we reached out to this list :-) and I think a lot of cool conversation is happening that I want to continue! It seems there is still value in finding a generalizable solution.

---

As for solutions that are *not* necessarily generalizable, what we were able to come up with is to use a 'unique-ified' email of the form <Sean+314159@corp.net>, where 314159 might be my employee ID. That way, even if another Sean might inherit <Sean@corp.net>, they can never inherit <Sean+314159@corp.net>. The use of this unique-ified email address will be enforced via pre-receive -- possibly checking for its existence in the mailmap as well.

Using this unique-ified email address, we can construct a mailmap like the following:

    Sean Allred <Sean@corp.net> <Sean+314159@corp.net>

This uses the already-built functionality of gitmailmap to interpret the committer email of <Sean+314159@corp.net> to the friendlier <Sean@corp.net> while still maintaining the requirement (for us) that the email on the commit be a real, usable email.

When I eventually get hit by a bus and give up <Sean@corp.net>, the mailmap can be updated to

    Sean Allred <devnull@corp.net> <Sean+314159@corp.net>
    Sean Allblue <Sean@corp.net> <Sean+271828@corp.net>

(possibly using some support list instead of <devnull@corp.net>).

This has proven itself in a few informal design chats already and is going to be the approach we take for our replay. I look forward to a future situation where we might be able to use SSH key validity periods instead :-) but that functionality will surely only be available after our migration in a few months' time.

I hope this helps others!

-- Sean Allred