Re: [PATCH v2] gitweb: map names/emails with mailmap
To
Eric Wong
Emma Brooks
Florian Mickler
Cc
Jeff King
git@vger.kernel.org
Jakub Narębski
From
Joe Perches
See Also
Prev Ref 1 Ref 2 Ref 3
Date
2020-08-11 06:33:55 UTC
On Tue, 2020-08-11 at 06:17 +0000, Eric Wong wrote:
> Emma Brooks <me@pluvano.com> wrote:
> > On 2020-08-10 06:02:49-0400, Jeff King wrote:
> > > There was a little discussion in response to v1 on whether we could
> > > reuse the existing C mailmap code:
> > > 
> > >   https://lore.kernel.org/git/20200731010129.GD240563@coredump.intra.peff.net/
> > > 
> > > Did you have any thoughts on that?
> > 
> > I think it's probably not worth the effort to make the necessary changes
> > to "rev-list --header" Junio mentioned, just for gitweb.
> > 
> > I agree it's a bit worrisome to have a second parser that could
> > potentially behave slightly differently than the main implementation.
> 
> +Cc Joe Perches
> 
> Fwiw, there's already a GPL-2.0 Perl .mailmap parser in
> scripts/get_maintainer.pl of the Linux kernel which Joe
> maintains:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/get_maintainer.pl

+cc Florian Mickler

Might be different behavior, dunno.

Florian Mickler wrote most of that and I
believe I rewrote it a bit, mostly for style.

If the perl code is useful to you, do what
you will with it, I give you my permission.

I don't believe get_maintainer needs to be
changed unless it's shown to be different
than what git does already.  I think it's
the same output.

> Been thinking about adding mailmap support to public-inbox in
> the send-email reply instructions, too.  (but public-inbox is
> AGPL-3+, so I can't steal the code w/o permission)
> 
> > What if we added tests for gitweb's mailmap parsing based on the same
> > cases used for Git itself?
> 
> That's probably fine IMHO; especially if it's just for gitweb display
> (and not writing anything that's meant to be stored forever).
> 
> There's already dozens of different parsers for email addresses,
> MIME, mailbox formats, etc. all with slightly different edge cases;
> things still mostly work well enough to not be a huge problem.
> (Same goes for Markdown, HTML, formats and even JSON :x)