Re: Dealing with corporate email recycling

[Sean Allred <allred.sean@gmail.com>]

Philip Oakley <philipoakley@iee.email> writes:
> The GDPR isn't as onerous as some suggest, as it isn't a set of black
> and white rules, rather in cases like these you need to have a real
> strong reason for why data is retained etc, such as being part of the
> verification and validation of the commit data. There have been various
> discussions around this in many of the technical journals.

That's good to hear that this has already been discussed in the
community (though I'm hardly surprised now that you mention it -- I'm
sure it was and remains a hot topic!).

> It maybe that your internal Git version could disable the particular
> `format` option ('%ae'?) for the original name, so only the designated
> ('redacted') mailmap entry is shown to casual users (assumes the repo is
> inside the corporate firewall). This would avoid invalidating the repos
> validation capability, while meeting the needs of GDPR type regulations.

I do want to note that at present we're not primarily concerned with
GDPR, but I am following up on that internally to see if there are any
considerations we need to make.  This is certainly an interesting tactic
for repositories that are hosted in GDPR-effective states, though.

> In the same vein, a local Git version could, being open source, add
> allowances for your extra mailmap entry details, such as adding a post
> fix " % <approxidate>" limits for the use of the particular name/email
> combo to allow date ranges to emerge.

I'd prefer the ability to agree on a pattern and merge support for it
upstream.  This way, forges can pick up support, too.  Bonus points if
the forge doesn't necessarily have to do more work than it already does.

Your " % <approxidate>" suggestion sounds a lot like the 'Valid-Before/
Valid-After' proposal from my original post in this thread (admittedly
not my idea).  Is there a compelling reason to use this approach over
UUIDs?  I ask not to suggest there isn't a compelling reason, but mostly
to make sure we consider the best arguments (and drawbacks) for any/all
approaches.

> I noted that all the .mailmap examples in the man page have ">" as the
> final character, but I haven't looked to see if the code always requires
> that the last element of the entry is an <email> address, or whether it
> currently barfs on extra elements.

FYI mailmap does support comment syntax (starting with # through \n).
It's worth noting that Ævar suggested earlier that perhaps we could
"(ab)use the comment syntax".  I tend to prefer their other approach,
though:

    > I.e. we simply ignore things we can't map now, so one way to do it
    > is to start with something that produces an invalid (but harmless)
    > mapping to current readers, [...]

rather than use magic comments :-) Adapting to your suggestion, this
might look like the following:

    A. U. Thor <foo@example.com> <ada.example.com> <[ approxidate ]>

Would be curious to know what other mailmap readers exist and how they
would react to this.

--
Sean Allred