Re: [PATCH RFC] mailmap: fix check-mailmap with full mailmap line
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 13, 2025, 23:45 UTC
- Message-ID
- <xmqqwmdtmmsl.fsf@gitster.g>
- In-Reply-To
- <20250213-jk-fix-sendemail-mailinfo-v1-1-c0b06c215f21@gmail.com>
Jacob Keller <jacob.e.keller@intel.com> 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@company.xx"
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@gmail.com
Show 11 quoted lines
> With a mailmap file containing: > > A <a@domain.com> B <b@domain.com> > > I get the following unexpected result: > > $ git check-mailmap b@domain.com > <b@domain.com> > > Based on my interpretation of the mailmap documentation, I would have > expected this to translate to "A <a@domain.com>".
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@domain.com" being answered by "<b@domain.com>" is quite expected from my point of view.
Thanks.