GitoxideLabs/gitoxide gix-mailmap-v0.34.0

gix-mailmap v0.34.0

on GitHub

Bug Fixes

• match Git when parsing a second mailmap identity

  Git treats the second name-and-email pair differently from the first: an
  empty email is accepted, and a malformed pair is ignored while retaining
  the mapping parsed from the first identity. Mirror those rules instead of
  rejecting the entire line.

  This also keeps arbitrary malformed trailing content from dropping an
  otherwise valid mapping.

• don't reject mailmap lines with content after the second email
  Git's read_mailmap_line() parses at most two name <email> pairs and
  discards whatever follows - the return value of the second
  parse_name_and_email() call is unused. gix-mailmap instead rejected
  any line with a non-empty remainder, and because Snapshot::from_bytes()
  goes through parse_ignore_errors(), those lines were silently dropped.

  Git's own .mailmap contains 16 such lines out of 305, and
  torvalds/linux's contains one. Line 230 of git.git's .mailmap:

  Philip Oakley <philipoakley@iee.email> <philipoakley@iee.org> # secondary <philipoakley@dunelm.org.uk>
  
  $ git check-mailmap 'Philip Oakley <philipoakley@iee.org>'
  Philip Oakley <philipoakley@iee.email>
  

  while gix_mailmap::Snapshot::resolve() returned the signature unchanged.

  The remainder check is replaced by Git's own condition: reject a line only
  when it contains no email at all, which is what if (email1) guards in
  read_mailmap_line(). Lines such as just a name therefore still produce
  an error, so parse() keeps reporting genuinely unparseable input. The
  message is reworded because "too many names or emails" can no longer
  happen.

  Resolving every name and email appearing in git.git's and linux's
  .mailmap - 904 and 2834 queries - now agrees with git check-mailmap
  in every case; 16 and 2 of them disagreed before.

Commit Statistics

• 5 commits contributed to the release over the course of 30 calendar days.
• 30 days passed between releases.
• 2 commits were understood as conventional.
• 0 issues like '(#ID)' were seen in commit messages

Commit Details