(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@xxxxxxxx>. If the owner of <Sean@xxxxxxxx>
leaves, I have the opportunity to take ownership of <Sean@xxxxxxxx>
after a waiting period. This presents the core problem: <Sean@xxxxxxxx>
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@xxxxxxxx>, where 314159 might be my employee ID. That way,
even if another Sean might inherit <Sean@xxxxxxxx>, they can never
inherit <Sean+314159@xxxxxxxx>. 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@xxxxxxxx> <Sean+314159@xxxxxxxx>
This uses the already-built functionality of gitmailmap to interpret the
committer email of <Sean+314159@xxxxxxxx> to the friendlier
<Sean@xxxxxxxx> 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@xxxxxxxx>, the
mailmap can be updated to
Sean Allred <devnull@xxxxxxxx> <Sean+314159@xxxxxxxx>
Sean Allblue <Sean@xxxxxxxx> <Sean+271828@xxxxxxxx>
(possibly using some support list instead of <devnull@xxxxxxxx>).
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
