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@xxxxxxxxx> writes: >>> >>>> rather than use magic comments :-) Adapting to your suggestion, this >>>> might look like the following: >>>> >>>> A. U. Thor <foo@xxxxxxxxxxx> <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.
