On Thu, Feb 13, 2025 at 3:45 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. > Re-reading the manual, that is a fair interpretation. I can share that with my coworker and he can adapt his mailmap to match this expectation I think. In that case, I think the simple fix is to just replace the NULL with a "" to resolve the segmentation fault and add a suitable test case for that? Thanks, Jake > Thanks.
