{"thread":{"id":"56479","subject":"[PATCH] .mailmap: Update mailmap","startedAt":"2021-09-10T13:02:54Z","lastAt":"2021-09-13T04:09:59Z","messageCount":13,"participants":["Fangyi Zhou","Gwyneth Morgan","Jeff King","Sibi Siddharthan","Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"435407","messageId":"20210910130236.40101-1-me@fangyi.io","threadId":"56479","inReplyTo":null,"subject":"[PATCH] .mailmap: Update mailmap","fromName":"Fangyi Zhou","fromEmail":"me@fangyi.io","sentAt":"2021-09-10T13:02:36Z","receivedAt":"2021-09-10T13:02:54Z","isPatch":true,"sender":{"key":"me@fangyi.io","avatar":"https://avatars.githubusercontent.com/u/7815439?v=4"},"body":"Similar to a35b13fce0 (Update .mailmap, 2018-11-09).\n\nThis patch makes the output of `git shortlog -nse v2.10.0..master`\nduplicate-free by taking/guessing the current and preferred\naddresses for authors that appear with more than one address.\n\nUpdated from <20200805065408.1242617-1-martin.agren@gmail.com>,\ntaking into consideration of ,\nand other replies.\n\nUse the by far most common e-mail address:\n * Brandon Williams\n * Jiang Xin\n\nUse the most recent e-mail address:\n * Birger Skogeng Pedersen\n * Christopher Díaz Riveros\n * Ed Maste\n * Fangyi Zhou\n * Jean-Noël Avila\n * Kevin Willford\n * Peter Kaestle\n\nUse the one from their \"Signed-off-by\":\n * Damien Robert\n * Kazuhiro Kato\n * Sibi Siddharthan\n\nUse the most recent name / name with correct accents:\n * CB Bailey\n * Christopher Díaz Riveros\n * Jessica Clarke\n * Slavica Đukić\n\nDo not merge:\n * Andreas Schwab\n\nSigned-off-by: Fangyi Zhou \n\n---\nPlease let me know if you approve those changes or not.\nIf no reply is received, the entry will be added in comments.\n\n---\n .mailmap | 23 +++++++++++++++++++++--\n 1 file changed, 21 insertions(+), 2 deletions(-)\n\ndiff --git a/.mailmap b/.mailmap\nindex 9c6a446bdf..ff0887d9e0 100644\n--- a/.mailmap\n+++ b/.mailmap\n@@ -27,13 +27,16 @@ Ben Peart \n Ben Walton \n Benoit Sigoure \n Bernt Hansen \n+Birger Skogeng Pedersen \n Brandon Casey \n Brandon Williams \n+Brandon Williams \n brian m. carlson \n brian m. carlson \n brian m. carlson \n Bryan Larsen \n Bryan Larsen \n+CB Bailey Charles Bailey\n Cheng Renquan \n Chris Shoemaker \n Chris Wright \n@@ -41,10 +44,12 @@ Christian Ludwig \n Cord Seele \n Christian Couder \n Christian Stimming \n-Christopher Díaz Riveros Christopher Diaz Riveros\n+Christopher Díaz Riveros \n+Christopher Díaz Riveros Christopher Diaz Riveros\n Clemens Buchacher \n Clemens Buchacher \n Csaba Henk \n+Damien Robert \n Dan Johnson \n Dana L. How \n Dana L. How Dana How\n@@ -64,13 +69,15 @@ Derrick Stolee Derrick Stolee via GitGitGadget \n Đoàn Trần Công Danh Doan Tran Cong Danh\n Dirk Süsserott \n+Ed Maste \n Eric Blake \n Eric Hanchrow \n Eric S. Raymond \n Eric Wong \n Erik Faye-Lund \n Eyvind Bernhardsen \n-Fangyi Zhou Zhou Fangyi\n+Fangyi Zhou \n+Fangyi Zhou Zhou Fangyi \n Florian Achleitner \n Franck Bui-Huu \n Frank Lichtenheld \n@@ -102,11 +109,14 @@ Jason Riedy \n Jay Soffian \n Jean-Noël Avila Jean-Noel Avila\n Jean-Noël Avila Jean-Noël AVILA\n+Jean-Noël Avila Jean-Noel Avila \n Jeff King \n Jeff Muizelaar \n Jens Axboe \n Jens Axboe \n Jens Lindström Jens Lindstrom \n+Jessica Clarke James Clarke\n+Jiang Xin \n Jim Meyering \n Joachim Berdal Haga \n Joachim Jablon \n@@ -138,10 +148,12 @@ Karsten Blees \n Karsten Blees \n Kay Sievers \n Kay Sievers \n+Kazuhiro Kato \n Kazuki Saitoh kazuki saitoh \n Keith Cascio \n Kent Engstrom \n Kevin Leung \n+Kevin Willford \n Kirill Smelkov \n Kirill Smelkov \n Knut Franke \n@@ -211,6 +223,7 @@ Peter Baumann \n Peter Krefting \n Peter Krefting \n+Peter Kaestle \n Petr Baudis \n Petr Baudis \n Phil Hord \n@@ -242,9 +255,11 @@ Sebastian Schuberth \n Seth Falcon \n Shawn O. Pearce \n Wei Shuyu Shuyu Wei\n+Sibi Siddharthan \n Sidhant Sharma Sidhant Sharma [:tk]\n Simon Hausmann \n Simon Hausmann \n+Slavica Đukić Slavica Djukic \n Stefan Beller \n Stefan Beller \n Stefan Naewe \n@@ -296,3 +311,7 @@ Yi-Jyun Pan \n anonymous \n anonymous \n İsmail Dönmez \n+\n+# Do not merge\n+# Andreas Schwab \n+# Andreas Schwab \n-- \n2.32.0\n\n"},{"id":"435428","messageId":"YTt4RymWg+TOEmUf@tilde.club","threadId":"56479","inReplyTo":"20210910130236.40101-1-me@fangyi.io","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Gwyneth Morgan","fromEmail":"gwymor@tilde.club","sentAt":"2021-09-10T15:22:47Z","receivedAt":"2021-09-10T15:23:24Z","isPatch":true,"sender":{"key":"gwymor@tilde.club","avatar":"https://avatars.githubusercontent.com/u/87623694?v=4"},"body":"On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:\n> Similar to a35b13fce0 (Update .mailmap, 2018-11-09).\n> \n> This patch makes the output of `git shortlog -nse v2.10.0..master`\n> duplicate-free by taking/guessing the current and preferred\n> addresses for authors that appear with more than one address.\n\nThe line for Jessica Clarke should probably just be\n\nJessica Clarke \n\nThat works the same and doesn't put a reference to an old name.\n"},{"id":"435431","messageId":"YTt6RTwJw64tYJRw@coredump.intra.peff.net","threadId":"56479","inReplyTo":"YTt4RymWg+TOEmUf@tilde.club","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-10T15:31:17Z","receivedAt":"2021-09-10T15:31:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:\n\n> On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:\n> > Similar to a35b13fce0 (Update .mailmap, 2018-11-09).\n> > \n> > This patch makes the output of `git shortlog -nse v2.10.0..master`\n> > duplicate-free by taking/guessing the current and preferred\n> > addresses for authors that appear with more than one address.\n> \n> The line for Jessica Clarke should probably just be\n> \n> Jessica Clarke \n> \n> That works the same and doesn't put a reference to an old name.\n\nThanks, that's a good suggestion. I kind of wonder if these mass\nmailmap-cleanup patches are a good idea in general. They are making\nassumptions about how people want their names to be represented, and\nwhether and how they want any mappings to appear. Maybe that's something\nwe should be leaving to people to propose for their own identities.\n\nOf course people who aren't active in the project anymore may not bother\nto do the cleanup, and of course messy data makes me sad. But on the\nwhole, I'm not sure it's that big a deal either way.\n\n-Peff\n"},{"id":"435432","messageId":"CAKw82xwnQLT-u4xnQZOiuM33=hC298dNt0eMna-KiMkq25fSow@mail.gmail.com","threadId":"56479","inReplyTo":"YTt6RTwJw64tYJRw@coredump.intra.peff.net","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Sibi Siddharthan","fromEmail":"sibisiv.siddharthan@gmail.com","sentAt":"2021-09-10T15:35:44Z","receivedAt":"2021-09-10T15:35:58Z","isPatch":true,"sender":{"key":"sibisiv.siddharthan@gmail.com","avatar":null},"body":"Hey there,\n\nPlease change the line 'Sibi Siddharthan\n '\nto\n'Sibi Siddharthan '.\nThe other one is my personal email.\n\nThank You,\nSibi Siddharthan\n"},{"id":"435449","messageId":"877dfocps2.fsf@evledraar.gmail.com","threadId":"56479","inReplyTo":"YTt4RymWg+TOEmUf@tilde.club","subject":"Oddidies in the .mailmap parser & future syntax extensions","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-10T16:48:26Z","receivedAt":"2021-09-10T17:19:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\n[Changed subject]\n\nOn Fri, Sep 10 2021, Gwyneth Morgan wrote:\n\n> On 2021-09-10 14:02:36+0100, Fangyi Zhou wrote:\n>> Similar to a35b13fce0 (Update .mailmap, 2018-11-09).\n>> \n>> This patch makes the output of `git shortlog -nse v2.10.0..master`\n>> duplicate-free by taking/guessing the current and preferred\n>> addresses for authors that appear with more than one address.\n>\n> The line for Jessica Clarke should probably just be\n>\n> Jessica Clarke \n>\n> That works the same and doesn't put a reference to an old name.\n\nIt does work exactly the same!\n\nMore specifically this is an unintentional bug/misfeature/looseness in\nthe .mailmap parser, an entry like:\n\n Foo Bar\n\nIs exactly equivalent to:\n\n Foo \n\nI.e. we simply ignore the \" Bar\" part. The reason for this is that we're\ninternally treating nonsense input as if the line simply ended there.\n\nEven having documented and tested some of this recently in 05b5ff219c2\n(mailmap doc + tests: add better examples & test them, 2021-01-12) I\nfound this a bit surprising. I probably found out at the time, but\nforgot and had to go source spelunking again.\n\nI'd expect:\n\n Foo Bar\n\nTo be an alias/shorthand for:\n\n Foo Bar \n\nWhich is something that might be applicable / useful in some\ncases.\n\nE.g. a name might change over time from \"Foo\", to \"Bar\", to \"Zar\", but\njust because we're at \"Bar\" and want to map \"Foo\" to \"Bar\", that might\nnot mean that we'd like to map any future name at the same address\n(i.e. the future \"Zar\") to the same \"Foo\".\n\nIn practice I suspect that's more commonly what people do want to do,\nmaybe we should warn about it, I did mean to hook some pedantic mode of\nthe parser at some point up to git-fsck.\n\nMore annoying is that this:\n\n New \n \n\nDoesn't mean the same as:\n\n New \n New \n\nI.e. I'd expect the name to map to the empty string, *unless* we saw an\nearlier address, i.e. just as we do for the first bar -> foo line (we\nmap it to a name of \"New\", we don't map it to an empty name).\n\nSo that's some #leftoverbits, perhaps someone somewhere relies on that,\nbut it seems like an obvious shorthand to have. I can't imagine it being\nuseful to map to empty names, and much of e.g. git.git's mailmap is\nrepeated entries with the same name over and over again.\n\nI suppose we could also extend it to new syntax such as:\n\n New \n\nDoing that would be strictly backwards compatible, i.e. now we'll\nentirely ignore the 3rd E-Mail address. It does mean we also\naccidentally support things like:\n\n New # A comment, because we ignore everything after the 2nd address\n\nBut don't tell anyone I told you that :) But that is something that\nmight technically have inadvertently closed the door to future syntax\nextensions, but we could probably do them anyway, or at worst have some\nheuristic.\n\nAnother useful thing might be to support:\n\n New <> Old <>\n\nAs an explicit mapping of the name \"Old\" wherever we see it to \"New\", or:\n\n New <> Old <>\n\nTo change just the name \"Old\" to \"New\" everywhere, without considering\nthe E-Mail address. Both of those are probably too crazy to be useful,\nespecially since if we supported that we'd logically also support:\n\n New <> <>\n\nTo assign all the commits to the name \"New\", but retain the address.\n"},{"id":"435455","messageId":"xmqq1r5wti5a.fsf@gitster.g","threadId":"56479","inReplyTo":"877dfocps2.fsf@evledraar.gmail.com","subject":"Re: Oddidies in the .mailmap parser & future syntax extensions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-10T18:11:45Z","receivedAt":"2021-09-10T18:12:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> [Changed subject]\n\n[jc: culled CC addresses]\n\n> I'd expect:\n>\n> Foo Bar\n>\n> To be an alias/shorthand for:\n>\n> Foo Bar \n\nOK.\n\n> More annoying is that this:\n>\n> New \n> \n>\n> Doesn't mean the same as:\n> ...\n> I.e. I'd expect the name to map to the empty string, *unless* we saw an\n> earlier address, i.e. just as we do for the first bar -> foo line (we\n> map it to a name of \"New\", we don't map it to an empty name).\n\nYou expect the first one to map (anyname, ) to\n(\"New\", ) and you describe the second one does not\nmap the human-readable part to \"New\", but it is unclear what the\ncode does, or why you expect it to map to \"\" (or what your\nexpectation is, for that matter, exactly---do you want an empty\nstring, or do you want \"New\", or something else???).\n\nFWIW, if we were designing it from scratch, I'd expect the second\none to map (anyname, ) to ($1, ),\nkeeping the human-readable part as-is and only map the e-mail part.\n\nOr do you expect that when these two entries appear together, the\nfirst entry with \"New\" is carried over to the second entry?\n\n> Doing that would be strictly backwards compatible, i.e. now we'll\n> entirely ignore the 3rd E-Mail address. It does mean we also\n> accidentally support things like:\n>\n> New # A comment, because we ignore everything after the 2nd address\n>\n> But don't tell anyone I told you that :) But that is something that\n> might technically have inadvertently closed the door to future syntax\n> extensions, but we could probably do them anyway, or at worst have some\n> heuristic.\n\nI vaguely recall that it was not an accident but a deliberate\nfeature to allow comments, but don't tell anyone I told you that.\n\n"},{"id":"435465","messageId":"87h7esb3ig.fsf@evledraar.gmail.com","threadId":"56479","inReplyTo":"xmqq1r5wti5a.fsf@gitster.g","subject":"Re: Oddidies in the .mailmap parser & future syntax extensions","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-10T19:50:28Z","receivedAt":"2021-09-10T20:05:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 10 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> [Changed subject]\n>\n> [jc: culled CC addresses]\n>\n>> I'd expect:\n>>\n>> Foo Bar\n>>\n>> To be an alias/shorthand for:\n>>\n>> Foo Bar \n>\n> OK.\n>\n>> More annoying is that this:\n>>\n>> New \n>> \n>>\n>> Doesn't mean the same as:\n>> ...\n>> I.e. I'd expect the name to map to the empty string, *unless* we saw an\n>> earlier address, i.e. just as we do for the first bar -> foo line (we\n>> map it to a name of \"New\", we don't map it to an empty name).\n>\n> You expect the first one to map (anyname, ) to\n> (\"New\", ) and you describe the second one does not\n> map the human-readable part to \"New\", but it is unclear what the\n> code does, or why you expect it to map to \"\" (or what your\n> expectation is, for that matter, exactly---do you want an empty\n> string, or do you want \"New\", or something else???).\n>\n> FWIW, if we were designing it from scratch, I'd expect the second\n> one to map (anyname, ) to ($1, ),\n> keeping the human-readable part as-is and only map the e-mail part.\n\nYes, that's what it does now. I.e. we'll create two mappings from those\nlines, namely (in line-by-line regex-like pseudosyntax):\n\n [[(.*), bar@example.com>] => [New, foo@example.com]]\n [[(.*), zar@example.com>] => [$1, foo@example.com]]\n\nI.e. for the second one we'll retain whatever name we found there.\n\n> Or do you expect that when these two entries appear together, the\n> first entry with \"New\" is carried over to the second entry?\n\nYes, I'd expect it to be stateful and implicitly do:\n\n [[(.*), bar@example.com>] => [New, foo@example.com]]\n [[(.*), zar@example.com>] => [find_last_name_for_address_in_mailmap(find_last_explicit_) || $1, foo@example.com]]\n\nI.e. we'd map the entries for you in git.git like:\n \n diff --git a/.mailmap b/.mailmap\n index 9c6a446bdfb..2a884981e9d 100644\n --- a/.mailmap\n +++ b/.mailmap\n @@ -127,8 +127,8 @@ Julian Phillips \n Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n + \n + \n + \n + \n + \n + \n\nWhich are currently mostly redundant, except for one old commit under\njunio@twinsun.com where the \" C \" wasn't present in your name field.\n\nOne might say that's a feature, and you'd like to be explicit about when\nto map addresses and when to map names, i.e. if we were trying to\nminimize the size of the .mailmap then this would be the most minimal\nthing we can get away with currently:\n \n diff --git a/.mailmap b/.mailmap\n index 9c6a446bdfb..4668f9b32f2 100644\n --- a/.mailmap\n +++ b/.mailmap\n @@ -127,8 +127,8 @@ Julian Phillips \n Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n + \n + \n + \n Junio C Hamano \n -Junio C Hamano \n -Junio C Hamano \n + \n + \n\nBut I just can't imagine cases where the proposed shorthand isn't useful\nfor everyone.\n\nWho wants to use mailmap, *and* map one e-mail address to another, *and*\nhas an entry explicitly mapping the name, but *would* mind having git be\nauto-smart and follow the chain of that explicit name mapping if there's\nan entry after that with an an e-mail -> that-earlier-email mapping?\n\nI think the answer is \"nobody\" and it would be unambiguously helpful,\nbut maybe I'm wrong.\n \n>> Doing that would be strictly backwards compatible, i.e. now we'll\n>> entirely ignore the 3rd E-Mail address. It does mean we also\n>> accidentally support things like:\n>>\n>> New # A comment, because we ignore everything after the 2nd address\n>>\n>> But don't tell anyone I told you that :) But that is something that\n>> might technically have inadvertently closed the door to future syntax\n>> extensions, but we could probably do them anyway, or at worst have some\n>> heuristic.\n>\n> I vaguely recall that it was not an accident but a deliberate\n> feature to allow comments, but don't tell anyone I told you that.\n\nWhich works, right until someone has an old name entry that looks like a\ncomment :)\n"},{"id":"435476","messageId":"xmqqk0jorxmx.fsf@gitster.g","threadId":"56479","inReplyTo":"87h7esb3ig.fsf@evledraar.gmail.com","subject":"Re: Oddidies in the .mailmap parser & future syntax extensions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-10T20:20:06Z","receivedAt":"2021-09-10T20:20:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Who wants to use mailmap, *and* map one e-mail address to another, *and*\n> has an entry explicitly mapping the name, but *would* mind having git be\n> auto-smart and follow the chain of that explicit name mapping if there's\n> an entry after that with an an e-mail -> that-earlier-email mapping?\n\nWould it make a difference if I point out that at least for our\nproject, we want to keep the .mailmap lines be sorted? I suspect\nthat a \"list must be mechanically sorted\" requirement may make it\nawkward to also have an \"if name is missing, use the last matching\nexplicit name\". Also, it makes removing one entry among many for\nthe same person less straight-forward (if you are removing the one\nthat happens to be listed first, you need to move the name to the\nnext entry in order to avoid losing it).\n\n"},{"id":"435493","messageId":"xmqqa6kkosst.fsf@gitster.g","threadId":"56479","inReplyTo":"YTt6RTwJw64tYJRw@coredump.intra.peff.net","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-09-11T00:32:50Z","receivedAt":"2021-09-11T00:32:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:\n>\n>> The line for Jessica Clarke should probably just be\n>> \n>> Jessica Clarke \n>> \n>> That works the same and doesn't put a reference to an old name.\n>\n> Thanks, that's a good suggestion. I kind of wonder if these mass\n> mailmap-cleanup patches are a good idea in general. They are making\n> assumptions about how people want their names to be represented, and\n> whether and how they want any mappings to appear. Maybe that's something\n> we should be leaving to people to propose for their own identities.\n>\n> Of course people who aren't active in the project anymore may not bother\n> to do the cleanup, and of course messy data makes me sad. But on the\n> whole, I'm not sure it's that big a deal either way.\n\nI am not enthused by the idea of replying to this thread, knowing\nthat many of the CC'ed addresses will bounce X-<, but I agree with\nyou on all three counts. Even for those who are no longer active,\nit makes sense to unify multiple idents that are spelled differently\nto help \"git shortlog\", but which one to unify to is not something\nwe can decide without their input.\n\nWhich leads me to suggest something like the attached patch. I\nwrote \"Please notify us\" for those who are no longer active and\nforgot how .mailmap entries are spelled to ask for help correcting.\n\nOf course, the updated instruction does not prevent a motivated\nvolunteer to contact the people _individually_ and then send in\na patch with entries that the volunteer secured consent, perhaps\nin the form of Acked-by ;-)\n\n\n .mailmap | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git i/.mailmap w/.mailmap\nindex 9c6a446bdf..20b581c879 100644\n--- i/.mailmap\n+++ w/.mailmap\n@@ -4,6 +4,11 @@\n # and/or not always written the same way, making contributions from the\n # same person appearing not to be so.\n #\n+# If you find an incorrect entry that affects yourself, please notify us\n+# at and suggest corrections. Because the way people\n+# want their names to be represented varies, please refrain from touching\n+# entries for other people unless you positively know that the updated\n+# entries are what they want.\n \n \n Alejandro R. Sedeño \n"},{"id":"435499","messageId":"87czpfc2j6.fsf@evledraar.gmail.com","threadId":"56479","inReplyTo":"xmqqa6kkosst.fsf@gitster.g","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-11T01:31:49Z","receivedAt":"2021-09-11T01:41:06Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 10 2021, Junio C Hamano wrote:\n\n> Jeff King writes:\n>\n>> On Fri, Sep 10, 2021 at 03:22:47PM +0000, Gwyneth Morgan wrote:\n>>\n>>> The line for Jessica Clarke should probably just be\n>>> \n>>> Jessica Clarke \n>>> \n>>> That works the same and doesn't put a reference to an old name.\n>>\n>> Thanks, that's a good suggestion. I kind of wonder if these mass\n>> mailmap-cleanup patches are a good idea in general. They are making\n>> assumptions about how people want their names to be represented, and\n>> whether and how they want any mappings to appear. Maybe that's something\n>> we should be leaving to people to propose for their own identities.\n>>\n>> Of course people who aren't active in the project anymore may not bother\n>> to do the cleanup, and of course messy data makes me sad. But on the\n>> whole, I'm not sure it's that big a deal either way.\n>\n> I am not enthused by the idea of replying to this thread, knowing\n> that many of the CC'ed addresses will bounce X-<, but I agree with\n> you on all three counts. Even for those who are no longer active,\n> it makes sense to unify multiple idents that are spelled differently\n> to help \"git shortlog\", but which one to unify to is not something\n> we can decide without their input.\n>\n> Which leads me to suggest something like the attached patch. I\n> wrote \"Please notify us\" for those who are no longer active and\n> forgot how .mailmap entries are spelled to ask for help correcting.\n>\n> Of course, the updated instruction does not prevent a motivated\n> volunteer to contact the people _individually_ and then send in\n> a patch with entries that the volunteer secured consent, perhaps\n> in the form of Acked-by ;-)\n>\n>\n> .mailmap | 5 +++++\n> 1 file changed, 5 insertions(+)\n>\n> diff --git i/.mailmap w/.mailmap\n> index 9c6a446bdf..20b581c879 100644\n> --- i/.mailmap\n> +++ w/.mailmap\n> @@ -4,6 +4,11 @@\n> # and/or not always written the same way, making contributions from the\n> # same person appearing not to be so.\n> #\n> +# If you find an incorrect entry that affects yourself, please notify us\n> +# at and suggest corrections. Because the way people\n> +# want their names to be represented varies, please refrain from touching\n> +# entries for other people unless you positively know that the updated\n> +# entries are what they want.\n> \n> \n> Alejandro R. Sedeño \n\nThat seems too high a burden for edits that are likely to be\nuncontroversial.\n\nI.e. this seems targeted at someone who's changing someone's name\nwithout their approval after the fact and when they can't be contacted.\n\nWhereas most if not all edits to this file are likely to be janitorial\nwork such as de-duplicating E-Mail addresses, or cases where the people\ninvolved even if they can't be contacted have already shared this\ninformation unambiguously with the world, it just happens to be in the\nmailing list archive, not in .mailmap.\n\nE.g. I'd think these were fine, even assuming you can't contact the\nparties involved:\n\n * The ML history reveals someone who's clearly the same person was\n using N E-Mail addresses in succession, we should probably map it all\n to the latest one, unclutters shortlog and the like.\n\n * Ditto even for their name in some cases. Is someone's commit history\n 200 commits of abbreviating their middle name, with 1-2 commits at\n the start where they don't? Seems fine to just normalize that.\n\n * Is the E-Mail they last used bouncing their E-Mails (\"this person\n doesn't work here anymore\"), domain expired etc?\n\n It would be useful to other contributors to map that to\n this-is-unreachable@example.org or whatever so they won't waste time\n CC-ing a bad address.\n\nWhich doesn't mean that there aren't things we shouldn't be doing\nwithout asking:\n\n * Changing a name from Alice to Bob? Yes, ask and have the person ack\n it.\n\n * Found the current E-Mail address someone who contributed years ago\n but not under that address to git.git? Ask them first, they may not\n wish to be contacted at all.\n\netc.\n"},{"id":"435555","messageId":"YTzBef1JuSCKl1tX@coredump.intra.peff.net","threadId":"56479","inReplyTo":"xmqqa6kkosst.fsf@gitster.g","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-11T14:47:21Z","receivedAt":"2021-09-11T14:47:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 10, 2021 at 05:32:50PM -0700, Junio C Hamano wrote:\n\n> Which leads me to suggest something like the attached patch. I\n> wrote \"Please notify us\" for those who are no longer active and\n> forgot how .mailmap entries are spelled to ask for help correcting.\n\nFWIW, that seems like a quite reasonable addition to me.\n\n-Peff\n"},{"id":"435556","messageId":"YTzCuAWCJESyxIfU@coredump.intra.peff.net","threadId":"56479","inReplyTo":"87czpfc2j6.fsf@evledraar.gmail.com","subject":"Re: [PATCH] .mailmap: Update mailmap","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-09-11T14:52:40Z","receivedAt":"2021-09-11T14:52:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[culling cc list as earlier]\n\nOn Sat, Sep 11, 2021 at 03:31:49AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Whereas most if not all edits to this file are likely to be janitorial\n> work such as de-duplicating E-Mail addresses, or cases where the people\n> involved even if they can't be contacted have already shared this\n> information unambiguously with the world, it just happens to be in the\n> mailing list archive, not in .mailmap.\n> \n> E.g. I'd think these were fine, even assuming you can't contact the\n> parties involved:\n> \n> * The ML history reveals someone who's clearly the same person was\n> using N E-Mail addresses in succession, we should probably map it all\n> to the latest one, unclutters shortlog and the like.\n\nJust playing devil's advocate for a moment. What about people who have\nused two different identities because they were contributing in two\ndifferent capacities (say, one from a work email, where they want to\ncontinue to credit that entity, and then later from a personal email).\n\nThat works against the goal of \"you can easily email the person from an\nold commit\". But it seems reasonable to respect their wishes there\n(e.g., they may not _want_ to deal with old contributions submitted\nas part of work).\n\nThe root of the problem is that we don't know their wishes, so we are\nmaking an assumption when a third party proposes the change.\n\n-Peff\n"},{"id":"435689","messageId":"87zgsh3ylo.fsf@evledraar.gmail.com","threadId":"56479","inReplyTo":"xmqqk0jorxmx.fsf@gitster.g","subject":"Re: Oddidies in the .mailmap parser & future syntax extensions","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-09-13T04:02:09Z","receivedAt":"2021-09-13T04:09:59Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Sep 10 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> Who wants to use mailmap, *and* map one e-mail address to another, *and*\n>> has an entry explicitly mapping the name, but *would* mind having git be\n>> auto-smart and follow the chain of that explicit name mapping if there's\n>> an entry after that with an an e-mail -> that-earlier-email mapping?\n>\n> Would it make a difference if I point out that at least for our\n> project, we want to keep the .mailmap lines be sorted?\n\nI just used git.git as a handy example. If the project wants to not use\nsome new shorthand syntax to make for easy sorting it can just not use\nit. I don't think that should be an argument against the existence of\nsuch a syntax for those who'd like it.\n\n> I suspect that a \"list must be mechanically sorted\" requirement may\n> make it awkward to also have an \"if name is missing, use the last\n> matching explicit name\". Also, it makes removing one entry among many\n> for the same person less straight-forward (if you are removing the one\n> that happens to be listed first, you need to move the name to the next\n> entry in order to avoid losing it).\n\nThat's a good point, that E-Mail was written rather off-hand, and I see\nfrom find_last_name_for_address_in_mailmap() that I probably had that\nordering in mind.\n\nBut given that point I think a shorthand like that would be equally or\nmore useful if we don't care about the order, the \"more\" being because\nyou'd be able to sort it in any way you like and still get the same\nresults.\n\nI.e. when mapping:\n\n \n \n\nWe'll have fully parsed the file, and having also seen:\n\n Junio C Hamano \n\nWe can follow the chain and see that since has\nexplicit wanted name mapping, that we should use that for say\n, because it wants to map to , so\nit should also get the name mapping.\n\nExcept if we had more than one name mapping, but that could/should also\nbe detected regardless of order.\n"}]}