Re: Dealing with corporate email recycling

[Philip Oakley <philipoakley@iee.email>]

On 14/03/2022 21:24, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> On 13/03/2022 23:16, Junio C Hamano wrote:
>>> Sean Allred <allred.sean@gmail.com> writes:
>>>
>>>> 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 ]>
>>> You'd probably want a timerange (valid-from and valid-to), instead
>>> of one single timestamp?
>> I'm not so sure that the date range approach won't bring it's own
>> problems. What happens outside the date range? i.e. Do we then have
>> three identities: Before, During, and After, with only 'During' being
>> defined?
> I have been assuming that the default is "what the commit has is
> correct".
That default is only true when there are no date limitations because of
email re-use. i.e. singleton persons with unique emails do fit that
default, which should be the majority.

If an old email has been reused, then that default becomes false, which
was Sean's starting point. In the corporate case, two (or more) distinct
individuals have used the same commit|author email address, and the hope
is, for a way of providing a disambiguation of those persons, based on
their email and the commit date.

>
>> I more see a single date being used as a termination point for an
>> existing email sequence that defines a retrospective end point for the
>> mapping of the old email addresses to a single person.
> Implicitly specifying the valid-from date (which is either the
> beginning of time, or the newest of valid-until time for the same
> identifying string that is older than the valid-until date for the
> entry in question) is fine.  I do not see fundamental difference
> between the approach you suggest and having an explicit valid-from
> date.
With the first case we guarantee that we have named cover for all of the
chronology via bisection, while the trisection can leave gaps without
any allocation to a person,  or possibly overlaps.

A more convoluted case would be where three persons share the same
emails in a rollover fashion, so the mailmap's simple name/email
handover becomes knotted and intertwined in the handovers
(Joe3->Joe2->Joe1).

P.