On Fri, Aug 16, 2024 at 7:06 PM Jacob Keller <jacob.e.keller@xxxxxxxxx> 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@xxxxxxxxxxx
> fatal: unable to parse contact: test@xxxxxxxxxxx
>
> 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 <jacob.keller@xxxxxxxxx>
