On Fri, Aug 16, 2024 at 7:06 PM Jacob Keller [off-list ref] wrote:

The git check-mailmap command can be used to convert identities to their
canonical real name and email address. Currently, if a simple email
address is provided without surrounding angle brackets, git
check-mailmap will fail:

  $ git check-mailmap test@example.com
  fatal: unable to parse contact: test@example.com

This is generally fine since identifies are expected to be of the form

s/identifies/identities/

"name <email@domain>". However, requiring brackets around simple email
addresses can make it difficult to support mailmap operation in other
environments where angle brackets may be missing.

Specifically, attempting to support the mailmap within git send-email is
tricky, since angle brackets are not always provided for addresses.

Teach check-mailmap a new '--no-brackets' mode. In this mode, any
contact line which cannot be interpreted by split_ident_line is treated
as a simple address without a name. In addition, when any contact does
not have a name, output the mail address without the angle brackets.
Note that angle brackets are accepted if they are present, however the
output will strip them.

What is not explained by the commit message is why we need this new
option as opposed to merely making git-check-mailmap accept such
addresses by default. Are there difficulties or downsides to making
this the default behavior? Do other things break if this new behavior
becomes the default as opposed to being an explicit opt-in?

This mode will be useful for git send-email in a following feature
implementation to enable mapping any email addresses to their canonical
value.

I'm a bit skeptical about how this new flag also changes the output
format to suppress the angle brackets. It seems like that's something
the caller could do easily enough if desired. For instance:

    $addr =~ s/^<(.*)>$/\1/;

Or, is there some deeper reason for doing this?

Signed-off-by: Jacob Keller <redacted>