[PATCH] .mailmap: Update mailmap

[PATCH] .mailmap: Update mailmap

[Fangyi Zhou]

Similar to a35b13fce0 (Update .mailmap, 2018-11-09).

This patch makes the output of `git shortlog -nse v2.10.0..master`
duplicate-free by taking/guessing the current and preferred
addresses for authors that appear with more than one address.

Updated from <20200805065408.1242617-1-martin.agren@gmail.com>,
taking into consideration of <xmqqsgcm4ij5.fsf@gitster.c.googlers.com>,
and other replies.

Use the by far most common e-mail address:
 * Brandon Williams
 * Jiang Xin

Use the most recent e-mail address:
 * Birger Skogeng Pedersen
 * Christopher Díaz Riveros
 * Ed Maste
 * Fangyi Zhou
 * Jean-Noël Avila
 * Kevin Willford
 * Peter Kaestle

Use the one from their "Signed-off-by":
 * Damien Robert
 * Kazuhiro Kato
 * Sibi Siddharthan

Use the most recent name / name with correct accents:
 * CB Bailey
 * Christopher Díaz Riveros
 * Jessica Clarke
 * Slavica Đukić

Do not merge:
 * Andreas Schwab

Signed-off-by: Fangyi Zhou <me@fangyi.io>

---
Please let me know if you approve those changes or not.
If no reply is received, the entry will be added in comments.

---
 .mailmap | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/.mailmap b/.mailmap
index 9c6a446bdf..ff0887d9e0 100644
--- a/.mailmap
+++ b/.mailmap
@@ -27,13 +27,16 @@ Ben Peart <benpeart@microsoft.com> <peartben@gmail.com>
 Ben Walton <bdwalton@gmail.com> <bwalton@artsci.utoronto.ca>
 Benoit Sigoure <tsunanet@gmail.com> <tsuna@lrde.epita.fr>
 Bernt Hansen <bernt@norang.ca> <bernt@alumni.uwaterloo.ca>
+Birger Skogeng Pedersen <birger.sp@gmail.com> <birgersp@gmail.com>
 Brandon Casey <drafnel@gmail.com> <casey@nrlssc.navy.mil>
 Brandon Williams <bwilliams.eng@gmail.com> <bmwill@google.com>
+Brandon Williams <bwilliamseng@gmail.com> <bmwill@google.com>
 brian m. carlson <sandals@crustytoothpaste.net>
 brian m. carlson <sandals@crustytoothpaste.net> <sandals@crustytoothpaste.ath.cx>
 brian m. carlson <sandals@crustytoothpaste.net> <bk2204@github.com>
 Bryan Larsen <bryan@larsen.st> <bryan.larsen@gmail.com>
 Bryan Larsen <bryan@larsen.st> <bryanlarsen@yahoo.com>
+CB Bailey <cbailey32@bloomberg.net> Charles Bailey
 Cheng Renquan <crquan@gmail.com>
 Chris Shoemaker <c.shoemaker@cox.net>
 Chris Wright <chrisw@sous-sol.org> <chrisw@osdl.org>
@@ -41,10 +44,12 @@ Christian Ludwig <chrissicool@gmail.com> <chrissicool@googlemail.com>
 Cord Seele <cowose@gmail.com> <cowose@googlemail.com>
 Christian Couder <chriscool@tuxfamily.org> <christian.couder@gmail.com>
 Christian Stimming <stimming@tuhh.de> <chs@ckiste.goetheallee>
-Christopher Díaz Riveros <chrisadr@gentoo.org> Christopher Diaz Riveros
+Christopher Díaz Riveros <christopher.diaz.riv@gmail.com> <chrisadr@gentoo.org>
+Christopher Díaz Riveros <christopher.diaz.riv@gmail.com> Christopher Diaz Riveros
 Clemens Buchacher <drizzd@gmx.net> <drizzd@aon.at>
 Clemens Buchacher <drizzd@gmx.net> <clemens.buchacher@intel.com>
 Csaba Henk <csaba@gluster.com> <csaba@lowlife.hu>
+Damien Robert <damien.olivier.robert+git@gmail.com> <damien.olivier.robert@gmail.com>
 Dan Johnson <computerdruid@gmail.com>
 Dana L. How <danahow@gmail.com> <how@deathvalley.cswitch.com>
 Dana L. How <danahow@gmail.com> Dana How
@@ -64,13 +69,15 @@ Derrick Stolee <dstolee@microsoft.com> Derrick Stolee via GitGitGadget <gitgitga
 Deskin Miller <deskinm@umich.edu>
 Đoàn Trần Công Danh <congdanhqx@gmail.com> Doan Tran Cong Danh
 Dirk Süsserott <newsletter@dirk.my1.cc>
+Ed Maste <emaste@FreeBSD.org> <emaste@freebsd.org>
 Eric Blake <eblake@redhat.com> <ebb9@byu.net>
 Eric Hanchrow <eric.hanchrow@gmail.com> <offby1@blarg.net>
 Eric S. Raymond <esr@thyrsus.com>
 Eric Wong <e@80x24.org> <normalperson@yhbt.net>
 Erik Faye-Lund <kusmabite@gmail.com> <kusmabite@googlemail.com>
 Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> <eyvind-git@orakel.ntnu.no>
-Fangyi Zhou <fangyi.zhou@yuriko.moe> Zhou Fangyi
+Fangyi Zhou <me@fangyi.io> <fangyi.zhou@yuriko.moe>
+Fangyi Zhou <me@fangyi.io> Zhou Fangyi <fangyi.zhou@yuriko.moe>
 Florian Achleitner <florian.achleitner.2.6.31@gmail.com> <florian.achleitner2.6.31@gmail.com>
 Franck Bui-Huu <vagabon.xyz@gmail.com> <fbuihuu@gmail.com>
 Frank Lichtenheld <frank@lichtenheld.de> <djpig@debian.org>
@@ -102,11 +109,14 @@ Jason Riedy <ejr@eecs.berkeley.edu> <ejr@cs.berkeley.edu>
 Jay Soffian <jaysoffian@gmail.com> <jaysoffian+git@gmail.com>
 Jean-Noël Avila <jn.avila@free.fr> Jean-Noel Avila
 Jean-Noël Avila <jn.avila@free.fr> Jean-Noël AVILA
+Jean-Noël Avila <jn.avila@free.fr> Jean-Noel Avila <jean-noel.avila@scantech.fr>
 Jeff King <peff@peff.net> <peff@github.com>
 Jeff Muizelaar <jmuizelaar@mozilla.com> <jeff@infidigm.net>
 Jens Axboe <axboe@kernel.dk> <axboe@suse.de>
 Jens Axboe <axboe@kernel.dk> <jens.axboe@oracle.com>
 Jens Lindström <jl@opera.com> Jens Lindstrom <jl@opera.com>
+Jessica Clarke <jrtc27@jrtc27.com> James Clarke
+Jiang Xin <worldhello.net@gmail.com> <zhiyou.jx@alibaba-inc.com>
 Jim Meyering <jim@meyering.net> <meyering@redhat.com>
 Joachim Berdal Haga <cjhaga@fys.uio.no>
 Joachim Jablon <joachim.jablon@people-doc.com> <ewjoachim@gmail.com>
@@ -138,10 +148,12 @@ Karsten Blees <blees@dcon.de> <karsten.blees@dcon.de>
 Karsten Blees <blees@dcon.de> <karsten.blees@gmail.com>
 Kay Sievers <kay.sievers@vrfy.org> <kay.sievers@suse.de>
 Kay Sievers <kay.sievers@vrfy.org> <kay@mam.(none)>
+Kazuhiro Kato <kato-k@ksysllc.co.jp> <kazuhiro.kato@hotmail.co.jp>
 Kazuki Saitoh <ksaitoh560@gmail.com> kazuki saitoh <ksaitoh560@gmail.com>
 Keith Cascio <keith@CS.UCLA.EDU> <keith@cs.ucla.edu>
 Kent Engstrom <kent@lysator.liu.se>
 Kevin Leung <kevinlsk@gmail.com>
+Kevin Willford <Kevin.Willford@microsoft.com> <kewillf@microsoft.com>
 Kirill Smelkov <kirr@navytux.spb.ru> <kirr@landau.phys.spbu.ru>
 Kirill Smelkov <kirr@navytux.spb.ru> <kirr@mns.spb.ru>
 Knut Franke <Knut.Franke@gmx.de> <k.franke@science-computing.de>
@@ -211,6 +223,7 @@ Peter Baumann <waste.manager@gmx.de> <Peter.B.Baumann@stud.informatik.uni-erlang
 Peter Baumann <waste.manager@gmx.de> <siprbaum@stud.informatik.uni-erlangen.de>
 Peter Krefting <peter@softwolves.pp.se> <peter@softwolves.pp.se>
 Peter Krefting <peter@softwolves.pp.se> <peter@svarten.intern.softwolves.pp.se>
+Peter Kaestle <peter@piie.net> <peter.kaestle@nokia.com>
 Petr Baudis <pasky@ucw.cz> <pasky@suse.cz>
 Petr Baudis <pasky@ucw.cz> <xpasky@machine>
 Phil Hord <hordp@cisco.com> <phil.hord@gmail.com>
@@ -242,9 +255,11 @@ Sebastian Schuberth <sschuberth@gmail.com> <sschuberth@visageimaging.com>
 Seth Falcon <seth@userprimary.net> <sfalcon@fhcrc.org>
 Shawn O. Pearce <spearce@spearce.org>
 Wei Shuyu <wsy@dogben.com> Shuyu Wei
+Sibi Siddharthan <sibisiddharthan.github@gmail.com> <sibisiv.siddharthan@gmail.com>
 Sidhant Sharma <tigerkid001@gmail.com> Sidhant Sharma [:tk]
 Simon Hausmann <hausmann@kde.org> <simon@lst.de>
 Simon Hausmann <hausmann@kde.org> <shausman@trolltech.com>
+Slavica Đukić <slawica92@hotmail.com> Slavica Djukic <slavicadj.ip2018@gmail.com>
 Stefan Beller <stefanbeller@gmail.com> <stefanbeller@googlemail.com>
 Stefan Beller <stefanbeller@gmail.com> <sbeller@google.com>
 Stefan Naewe <stefan.naewe@gmail.com> <stefan.naewe@atlas-elektronik.com>
@@ -296,3 +311,7 @@ Yi-Jyun Pan <pan93412@gmail.com>
 anonymous <linux@horizon.com>
 anonymous <linux@horizon.net>
 İsmail Dönmez <ismail@pardus.org.tr>
+
+# Do not merge
+# Andreas Schwab <schwab@linux-m68k.org>
+# Andreas Schwab <schwab@suse.de>
-- 
2.32.0

Re: [PATCH] .mailmap: Update mailmap

[Gwyneth Morgan]

On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:
> Similar to a35b13fce0 (Update .mailmap, 2018-11-09).
> 
> This patch makes the output of `git shortlog -nse v2.10.0..master`
> duplicate-free by taking/guessing the current and preferred
> addresses for authors that appear with more than one address.

The line for Jessica Clarke should probably just be

Jessica Clarke <jrtc27@jrtc27.com>

That works the same and doesn't put a reference to an old name.

Re: [PATCH] .mailmap: Update mailmap

[Jeff King]

On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:

> On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:
> > Similar to a35b13fce0 (Update .mailmap, 2018-11-09).
> > 
> > This patch makes the output of `git shortlog -nse v2.10.0..master`
> > duplicate-free by taking/guessing the current and preferred
> > addresses for authors that appear with more than one address.
> 
> The line for Jessica Clarke should probably just be
> 
> Jessica Clarke <jrtc27@jrtc27.com>
> 
> That works the same and doesn't put a reference to an old name.

Thanks, that's a good suggestion. I kind of wonder if these mass
mailmap-cleanup patches are a good idea in general. They are making
assumptions about how people want their names to be represented, and
whether and how they want any mappings to appear. Maybe that's something
we should be leaving to people to propose for their own identities.

Of course people who aren't active in the project anymore may not bother
to do the cleanup, and of course messy data makes me sad. But on the
whole, I'm not sure it's that big a deal either way.

-Peff

Re: [PATCH] .mailmap: Update mailmap

[Sibi Siddharthan]

Hey there,

Please change the line 'Sibi Siddharthan
<sibisiddharthan.github@gmail.com> <sibisiv.siddharthan@gmail.com>'
to
'Sibi Siddharthan <sibisiddharthan.github@gmail.com>'.
The other one is my personal email.

Thank You,
Sibi Siddharthan

Oddidies in the .mailmap parser & future syntax extensions

[Ævar Arnfjörð Bjarmason]

[Changed subject]

On Fri, Sep 10 2021, Gwyneth Morgan wrote:

> On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:
>> Similar to a35b13fce0 (Update .mailmap, 2018-11-09).
>> 
>> This patch makes the output of `git shortlog -nse v2.10.0..master`
>> duplicate-free by taking/guessing the current and preferred
>> addresses for authors that appear with more than one address.
>
> The line for Jessica Clarke should probably just be
>
> Jessica Clarke <jrtc27@jrtc27.com>
>
> That works the same and doesn't put a reference to an old name.

It does work exactly the same!

More specifically this is an unintentional bug/misfeature/looseness in
the .mailmap parser, an entry like:

    Foo <foo@example.com> Bar

Is exactly equivalent to:

    Foo <foo@example.com>

I.e. we simply ignore the " Bar" part. The reason for this is that we're
internally treating nonsense input as if the line simply ended there.

Even having documented and tested some of this recently in 05b5ff219c2
(mailmap doc + tests: add better examples & test them, 2021-01-12) I
found this a bit surprising. I probably found out at the time, but
forgot and had to go source spelunking again.

I'd expect:

    Foo <foo@example.com> Bar

To be an alias/shorthand for:

    Foo <foo@example.com> Bar <foo@example.com>

Which is something that might be applicable / useful in some
cases.

E.g. a name might change over time from "Foo", to "Bar", to "Zar", but
just because we're at "Bar" and want to map "Foo" to "Bar", that might
not mean that we'd like to map any future name at the same address
(i.e. the future "Zar") to the same "Foo".

In practice I suspect that's more commonly what people do want to do,
maybe we should warn about it, I did mean to hook some pedantic mode of
the parser at some point up to git-fsck.

More annoying is that this:

    New <foo@example.com> <bar@example.com>
    <foo@example.com> <zar@example.com>

Doesn't mean the same as:

    New <foo@example.com> <bar@example.com>
    New <foo@example.com> <zar@example.com>

I.e. I'd expect the name to map to the empty string, *unless* we saw an
earlier address, i.e. just as we do for the first bar -> foo line (we
map it to a name of "New", we don't map it to an empty name).

So that's some #leftoverbits, perhaps someone somewhere relies on that,
but it seems like an obvious shorthand to have. I can't imagine it being
useful to map to empty names, and much of e.g. git.git's mailmap is
repeated entries with the same name over and over again.

I suppose we could also extend it to new syntax such as:

    New <foo@example.com> <bar@example.com> <zar@example.com>

Doing that would be strictly backwards compatible, i.e. now we'll
entirely ignore the 3rd E-Mail address. It does mean we also
accidentally support things like:

    New <foo@example.com> <bar@example.com> # A comment, because we ignore everything after the 2nd address

But don't tell anyone I told you that :) But that is something that
might technically have inadvertently closed the door to future syntax
extensions, but we could probably do them anyway, or at worst have some
heuristic.

Another useful thing might be to support:

    New <> Old <>

As an explicit mapping of the name "Old" wherever we see it to "New", or:

    New <> Old <>

To change just the name "Old" to "New" everywhere, without considering
the E-Mail address. Both of those are probably too crazy to be useful,
especially since if we supported that we'd logically also support:

    New <> <>

To assign all the commits to the name "New", but retain the address.

Re: Oddidies in the .mailmap parser & future syntax extensions

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> [Changed subject]

[jc: culled CC addresses]

> I'd expect:
>
>     Foo <foo@example.com> Bar
>
> To be an alias/shorthand for:
>
>     Foo <foo@example.com> Bar <foo@example.com>

OK.

> More annoying is that this:
>
>     New <foo@example.com> <bar@example.com>
>     <foo@example.com> <zar@example.com>
>
> Doesn't mean the same as:
> ...
> I.e. I'd expect the name to map to the empty string, *unless* we saw an
> earlier address, i.e. just as we do for the first bar -> foo line (we
> map it to a name of "New", we don't map it to an empty name).

You expect the first one to map (anyname, <bar@example.com>) to
("New", <foo@example.com>) and you describe the second one does not
map the human-readable part to "New", but it is unclear what the
code does, or why you expect it to map to "" (or what your
expectation is, for that matter, exactly---do you want an empty
string, or do you want "New", or something else???).

FWIW, if we were designing it from scratch, I'd expect the second
one to map (anyname, <zar@example.com>) to ($1, <foo@example.com>),
keeping the human-readable part as-is and only map the e-mail part.

Or do you expect that when these two entries appear together, the
first entry with "New" is carried over to the second entry?

> Doing that would be strictly backwards compatible, i.e. now we'll
> entirely ignore the 3rd E-Mail address. It does mean we also
> accidentally support things like:
>
>     New <foo@example.com> <bar@example.com> # A comment, because we ignore everything after the 2nd address
>
> But don't tell anyone I told you that :) But that is something that
> might technically have inadvertently closed the door to future syntax
> extensions, but we could probably do them anyway, or at worst have some
> heuristic.

I vaguely recall that it was not an accident but a deliberate
feature to allow comments, but don't tell anyone I told you that.

Re: Oddidies in the .mailmap parser & future syntax extensions

[Ævar Arnfjörð Bjarmason]

On Fri, Sep 10 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> [Changed subject]
>
> [jc: culled CC addresses]
>
>> I'd expect:
>>
>>     Foo <foo@example.com> Bar
>>
>> To be an alias/shorthand for:
>>
>>     Foo <foo@example.com> Bar <foo@example.com>
>
> OK.
>
>> More annoying is that this:
>>
>>     New <foo@example.com> <bar@example.com>
>>     <foo@example.com> <zar@example.com>
>>
>> Doesn't mean the same as:
>> ...
>> I.e. I'd expect the name to map to the empty string, *unless* we saw an
>> earlier address, i.e. just as we do for the first bar -> foo line (we
>> map it to a name of "New", we don't map it to an empty name).
>
> You expect the first one to map (anyname, <bar@example.com>) to
> ("New", <foo@example.com>) and you describe the second one does not
> map the human-readable part to "New", but it is unclear what the
> code does, or why you expect it to map to "" (or what your
> expectation is, for that matter, exactly---do you want an empty
> string, or do you want "New", or something else???).
>
> FWIW, if we were designing it from scratch, I'd expect the second
> one to map (anyname, <zar@example.com>) to ($1, <foo@example.com>),
> keeping the human-readable part as-is and only map the e-mail part.

Yes, that's what it does now. I.e. we'll create two mappings from those
lines, namely (in line-by-line regex-like pseudosyntax):

    [[(.*), bar@example.com>] => [New, foo@example.com]]
    [[(.*), zar@example.com>] => [$1, foo@example.com]]

I.e. for the second one we'll retain whatever name we found there.

> Or do you expect that when these two entries appear together, the
> first entry with "New" is carried over to the second entry?

Yes, I'd expect it to be stateful and implicitly do:

    [[(.*), bar@example.com>] => [New, foo@example.com]]
    [[(.*), zar@example.com>] => [find_last_name_for_address_in_mailmap(find_last_explicit_) || $1, foo@example.com]]

I.e. we'd map the entries for you in git.git like:
    
    diff --git a/.mailmap b/.mailmap
    index 9c6a446bdfb..2a884981e9d 100644
    --- a/.mailmap
    +++ b/.mailmap
    @@ -127,8 +127,8 @@ Julian Phillips <julian@quantumfyre.co.uk> <jp3@quantumfyre.co.uk>
     Junio C Hamano <gitster@pobox.com> <gitster@pobox.com>
    -Junio C Hamano <gitster@pobox.com> <junio@hera.kernel.org>
    -Junio C Hamano <gitster@pobox.com> <junio@kernel.org>
    -Junio C Hamano <gitster@pobox.com> <junio@pobox.com>
    -Junio C Hamano <gitster@pobox.com> <junio@twinsun.com>
    -Junio C Hamano <gitster@pobox.com> <junkio@cox.net>
    -Junio C Hamano <gitster@pobox.com> <junkio@twinsun.com>
    +<gitster@pobox.com> <junio@hera.kernel.org>
    +<gitster@pobox.com> <junio@kernel.org>
    +<gitster@pobox.com> <junio@pobox.com>
    +<gitster@pobox.com> <junio@twinsun.com>
    +<gitster@pobox.com> <junkio@cox.net>
    +<gitster@pobox.com> <junkio@twinsun.com>

Which are currently mostly redundant, except for one old commit under
junio@twinsun.com where the " C " wasn't present in your name field.

One might say that's a feature, and you'd like to be explicit about when
to map addresses and when to map names, i.e. if we were trying to
minimize the size of the .mailmap then this would be the most minimal
thing we can get away with currently:
    
    diff --git a/.mailmap b/.mailmap
    index 9c6a446bdfb..4668f9b32f2 100644
    --- a/.mailmap
    +++ b/.mailmap
    @@ -127,8 +127,8 @@ Julian Phillips <julian@quantumfyre.co.uk> <jp3@quantumfyre.co.uk>
     Junio C Hamano <gitster@pobox.com> <gitster@pobox.com>
    -Junio C Hamano <gitster@pobox.com> <junio@hera.kernel.org>
    -Junio C Hamano <gitster@pobox.com> <junio@kernel.org>
    -Junio C Hamano <gitster@pobox.com> <junio@pobox.com>
    +<gitster@pobox.com> <junio@hera.kernel.org>
    +<gitster@pobox.com> <junio@kernel.org>
    +<gitster@pobox.com> <junio@pobox.com>
     Junio C Hamano <gitster@pobox.com> <junio@twinsun.com>
    -Junio C Hamano <gitster@pobox.com> <junkio@cox.net>
    -Junio C Hamano <gitster@pobox.com> <junkio@twinsun.com>
    +<gitster@pobox.com> <junkio@cox.net>
    +<gitster@pobox.com> <junkio@twinsun.com>

But I just can't imagine cases where the proposed shorthand isn't useful
for everyone.

Who wants to use mailmap, *and* map one e-mail address to another, *and*
has an entry explicitly mapping the name, but *would* mind having git be
auto-smart and follow the chain of that explicit name mapping if there's
an entry after that with an an e-mail -> that-earlier-email mapping?

I think the answer is "nobody" and it would be unambiguously helpful,
but maybe I'm wrong.
    
>> Doing that would be strictly backwards compatible, i.e. now we'll
>> entirely ignore the 3rd E-Mail address. It does mean we also
>> accidentally support things like:
>>
>>     New <foo@example.com> <bar@example.com> # A comment, because we ignore everything after the 2nd address
>>
>> But don't tell anyone I told you that :) But that is something that
>> might technically have inadvertently closed the door to future syntax
>> extensions, but we could probably do them anyway, or at worst have some
>> heuristic.
>
> I vaguely recall that it was not an accident but a deliberate
> feature to allow comments, but don't tell anyone I told you that.

Which works, right until someone has an old name entry that looks like a
comment :)

Re: Oddidies in the .mailmap parser & future syntax extensions

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Who wants to use mailmap, *and* map one e-mail address to another, *and*
> has an entry explicitly mapping the name, but *would* mind having git be
> auto-smart and follow the chain of that explicit name mapping if there's
> an entry after that with an an e-mail -> that-earlier-email mapping?

Would it make a difference if I point out that at least for our
project, we want to keep the .mailmap lines be sorted?  I suspect
that a "list must be mechanically sorted" requirement may make it
awkward to also have an "if name is missing, use the last matching
explicit name".  Also, it makes removing one entry among many for
the same person less straight-forward (if you are removing the one
that happens to be listed first, you need to move the name to the
next entry in order to avoid losing it).

Re: [PATCH] .mailmap: Update mailmap

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:
>
>> The line for Jessica Clarke should probably just be
>> 
>> Jessica Clarke <jrtc27@jrtc27.com>
>> 
>> That works the same and doesn't put a reference to an old name.
>
> Thanks, that's a good suggestion. I kind of wonder if these mass
> mailmap-cleanup patches are a good idea in general. They are making
> assumptions about how people want their names to be represented, and
> whether and how they want any mappings to appear. Maybe that's something
> we should be leaving to people to propose for their own identities.
>
> Of course people who aren't active in the project anymore may not bother
> to do the cleanup, and of course messy data makes me sad. But on the
> whole, I'm not sure it's that big a deal either way.

I am not enthused by the idea of replying to this thread, knowing
that many of the CC'ed addresses will bounce X-<, but I agree with
you on all three counts.  Even for those who are no longer active,
it makes sense to unify multiple idents that are spelled differently
to help "git shortlog", but which one to unify to is not something
we can decide without their input.

Which leads me to suggest something like the attached patch.  I
wrote "Please notify us" for those who are no longer active and
forgot how .mailmap entries are spelled to ask for help correcting.

Of course, the updated instruction does not prevent a motivated
volunteer to contact the people _individually_ and then send in
a patch with entries that the volunteer secured consent, perhaps
in the form of Acked-by ;-)


 .mailmap | 5 +++++
 1 file changed, 5 insertions(+)

diff --git i/.mailmap w/.mailmap
index 9c6a446bdf..20b581c879 100644
--- i/.mailmap
+++ w/.mailmap
@@ -4,6 +4,11 @@
 # and/or not always written the same way, making contributions from the
 # same person appearing not to be so.
 #
+# If you find an incorrect entry that affects yourself, please notify us
+# at <git@vger.kernel.org> and suggest corrections.  Because the way people
+# want their names to be represented varies, please refrain from touching
+# entries for other people unless you positively know that the updated
+# entries are what they want.
 
 <nico@fluxnic.net> <nico@cam.org>
 Alejandro R. Sedeño <asedeno@MIT.EDU> <asedeno@mit.edu>

Re: [PATCH] .mailmap: Update mailmap

[Ævar Arnfjörð Bjarmason]

On Fri, Sep 10 2021, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
>
>> On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:
>>
>>> The line for Jessica Clarke should probably just be
>>> 
>>> Jessica Clarke <jrtc27@jrtc27.com>
>>> 
>>> That works the same and doesn't put a reference to an old name.
>>
>> Thanks, that's a good suggestion. I kind of wonder if these mass
>> mailmap-cleanup patches are a good idea in general. They are making
>> assumptions about how people want their names to be represented, and
>> whether and how they want any mappings to appear. Maybe that's something
>> we should be leaving to people to propose for their own identities.
>>
>> Of course people who aren't active in the project anymore may not bother
>> to do the cleanup, and of course messy data makes me sad. But on the
>> whole, I'm not sure it's that big a deal either way.
>
> I am not enthused by the idea of replying to this thread, knowing
> that many of the CC'ed addresses will bounce X-<, but I agree with
> you on all three counts.  Even for those who are no longer active,
> it makes sense to unify multiple idents that are spelled differently
> to help "git shortlog", but which one to unify to is not something
> we can decide without their input.
>
> Which leads me to suggest something like the attached patch.  I
> wrote "Please notify us" for those who are no longer active and
> forgot how .mailmap entries are spelled to ask for help correcting.
>
> Of course, the updated instruction does not prevent a motivated
> volunteer to contact the people _individually_ and then send in
> a patch with entries that the volunteer secured consent, perhaps
> in the form of Acked-by ;-)
>
>
>  .mailmap | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git i/.mailmap w/.mailmap
> index 9c6a446bdf..20b581c879 100644
> --- i/.mailmap
> +++ w/.mailmap
> @@ -4,6 +4,11 @@
>  # and/or not always written the same way, making contributions from the
>  # same person appearing not to be so.
>  #
> +# If you find an incorrect entry that affects yourself, please notify us
> +# at <git@vger.kernel.org> and suggest corrections.  Because the way people
> +# want their names to be represented varies, please refrain from touching
> +# entries for other people unless you positively know that the updated
> +# entries are what they want.
>  
>  <nico@fluxnic.net> <nico@cam.org>
>  Alejandro R. Sedeño <asedeno@MIT.EDU> <asedeno@mit.edu>

That seems too high a burden for edits that are likely to be
uncontroversial.

I.e. this seems targeted at someone who's changing someone's name
without their approval after the fact and when they can't be contacted.

Whereas most if not all edits to this file are likely to be janitorial
work such as de-duplicating E-Mail addresses, or cases where the people
involved even if they can't be contacted have already shared this
information unambiguously with the world, it just happens to be in the
mailing list archive, not in .mailmap.

E.g. I'd think these were fine, even assuming you can't contact the
parties involved:

 * The ML history reveals someone who's clearly the same person was
   using N E-Mail addresses in succession, we should probably map it all
   to the latest one, unclutters shortlog and the like.

 * Ditto even for their name in some cases. Is someone's commit history
   200 commits of abbreviating their middle name, with 1-2 commits at
   the start where they don't? Seems fine to just normalize that.

 * Is the E-Mail they last used bouncing their E-Mails ("this person
   doesn't work here anymore"), domain expired etc?

   It would be useful to other contributors to map that to
   this-is-unreachable@example.org or whatever so they won't waste time
   CC-ing a bad address.

Which doesn't mean that there aren't things we shouldn't be doing
without asking:

 * Changing a name from Alice to Bob? Yes, ask and have the person ack
   it.

 * Found the current E-Mail address someone who contributed years ago
   but not under that address to git.git? Ask them first, they may not
   wish to be contacted at all.

etc.

Re: [PATCH] .mailmap: Update mailmap

[Jeff King]

On Fri, Sep 10, 2021 at 05:32:50PM -0700, Junio C Hamano wrote:

> Which leads me to suggest something like the attached patch.  I
> wrote "Please notify us" for those who are no longer active and
> forgot how .mailmap entries are spelled to ask for help correcting.

FWIW, that seems like a quite reasonable addition to me.

-Peff

Re: [PATCH] .mailmap: Update mailmap

[Jeff King]

[culling cc list as earlier]

On Sat, Sep 11, 2021 at 03:31:49AM +0200, Ævar Arnfjörð Bjarmason wrote:

> Whereas most if not all edits to this file are likely to be janitorial
> work such as de-duplicating E-Mail addresses, or cases where the people
> involved even if they can't be contacted have already shared this
> information unambiguously with the world, it just happens to be in the
> mailing list archive, not in .mailmap.
> 
> E.g. I'd think these were fine, even assuming you can't contact the
> parties involved:
> 
>  * The ML history reveals someone who's clearly the same person was
>    using N E-Mail addresses in succession, we should probably map it all
>    to the latest one, unclutters shortlog and the like.

Just playing devil's advocate for a moment. What about people who have
used two different identities because they were contributing in two
different capacities (say, one from a work email, where they want to
continue to credit that entity, and then later from a personal email).

That works against the goal of "you can easily email the person from an
old commit". But it seems reasonable to respect their wishes there
(e.g., they may not _want_ to deal with old contributions submitted
as part of work).

The root of the problem is that we don't know their wishes, so we are
making an assumption when a third party proposes the change.

-Peff

Re: Oddidies in the .mailmap parser & future syntax extensions

[Ævar Arnfjörð Bjarmason]

On Fri, Sep 10 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Who wants to use mailmap, *and* map one e-mail address to another, *and*
>> has an entry explicitly mapping the name, but *would* mind having git be
>> auto-smart and follow the chain of that explicit name mapping if there's
>> an entry after that with an an e-mail -> that-earlier-email mapping?
>
> Would it make a difference if I point out that at least for our
> project, we want to keep the .mailmap lines be sorted?

I just used git.git as a handy example. If the project wants to not use
some new shorthand syntax to make for easy sorting it can just not use
it. I don't think that should be an argument against the existence of
such a syntax for those who'd like it.

> I suspect that a "list must be mechanically sorted" requirement may
> make it awkward to also have an "if name is missing, use the last
> matching explicit name".  Also, it makes removing one entry among many
> for the same person less straight-forward (if you are removing the one
> that happens to be listed first, you need to move the name to the next
> entry in order to avoid losing it).

That's a good point, that E-Mail was written rather off-hand, and I see
from find_last_name_for_address_in_mailmap() that I probably had that
ordering in mind.

But given that point I think a shorthand like that would be equally or
more useful if we don't care about the order, the "more" being because
you'd be able to sort it in any way you like and still get the same
results.

I.e. when mapping:

    <gitster@pobox.com> <junio@hera.kernel.org>
    <gitster@pobox.com> <junio@kernel.org>

We'll have fully parsed the file, and having also seen:

    Junio C Hamano <gitster@pobox.com> <gitster@pobox.com>

We can follow the chain and see that since <gitster@pobox.com> has
explicit wanted name mapping, that we should use that for say
<junio@kernel.org>, because it wants to map to <gitster@pobox.com>, so
it should also get the name mapping.

Except if we had more than one name mapping, but that could/should also
be detected regardless of order.