Re: [PATCH RFC] mailmap: fix check-mailmap with full mailmap line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jacob Keller <jacob.e.keller@xxxxxxxxx> writes:

> I recently had reported to me a crash from a coworker using the recently
> added sendemail mailmap support:
>
>   3724814 Segmentation fault      (core dumped) git check-mailmap "bugs@xxxxxxxxxx"

Thanks for relaying the report.
    
I can easily reproduce your segfault with our own mailmap, by
picking at random an entry with both name and e-mail listed as
the mapping source, e.g.

    $ git check-mailmap ksaitoh560@xxxxxxxxx

> With a mailmap file containing:
>
> A <a@xxxxxxxxxx> B <b@xxxxxxxxxx>
>
> I get the following unexpected result:
>
> $ git check-mailmap b@xxxxxxxxxx
> <b@xxxxxxxxxx>
>
> Based on my interpretation of the mailmap documentation, I would have
> expected this to translate to "A <a@xxxxxxxxxx>".

After reading "git help mailmap" twice, my interpretation is
different (disclaimer: I haven't read the implementation of the
mailmap code lately, and the last time I read any part of it is
probably at least a few years ago if not before).

Unlike "please map anybody with this e-mail address to 'A <a>'"
entry, which is spelled "A <a> <b>", the "fully spelled" form limits
the damage to those that match both name and e-mail, in order to
avoid "D <b>" from getting modified, while rewriting "B <b>" to "A
<a>".  So I would not expect a request with no name to be mapped at
all.

And the command emits the e-mail intact when it does not find any
match, "b@xxxxxxxxxx" being answered by "<b@xxxxxxxxxx>" is quite
expected from my point of view.

Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux