| Message ID | 20210910130236.40101-1-me@fangyi.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | .mailmap: Update mailmap | expand |
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.
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
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
[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.
Æ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.
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 :)
Æ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).
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>
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.
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
[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
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.
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>
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(-)