git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Josh Steadmon <steadmon@google.com>, <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH 1/2] check-mailmap: add --no-brackets mode
Date: Fri, 16 Aug 2024 16:42:32 -0700	[thread overview]
Message-ID: <cf58f786-06b0-4ad3-a6fd-f593af639c98@intel.com> (raw)
In-Reply-To: <CAPig+cSN-KU-TQ5UBR9KfxjmQ4zzjL-Y-anxDe9FaeqsV=1Xww@mail.gmail.com>



On 8/16/2024 4:22 PM, Eric Sunshine wrote:
> On Fri, Aug 16, 2024 at 7:06 PM Jacob Keller <jacob.e.keller@intel.com> 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?
> 

Mostly I did it this way out of conservative caution to avoid breaking
existing users. It could be that nothing breaks and loosening the
restriction on what we pass it would be sufficient.

>> 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?
> 

For one, the documentation of git check-mailmap specifies that it passes
other values through "as-is", but this mode would convert
"user@example.com" to "<user@example.com>"

I suppose thats not a big deal, and it was more a matter of not wanting
to bother the caller to force it to strip any brackets if it didn't want
them. I think its probably fine to require that.

>> Signed-off-by: Jacob Keller <jacob.keller@gmail.com>

  reply	other threads:[~2024-08-16 23:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 23:06 [PATCH 0/2] send-email: add --mailmap support Jacob Keller
2024-08-16 23:06 ` [PATCH 1/2] check-mailmap: add --no-brackets mode Jacob Keller
2024-08-16 23:22   ` Eric Sunshine
2024-08-16 23:42     ` Jacob Keller [this message]
2024-08-16 23:51       ` Eric Sunshine
2024-08-16 23:06 ` [PATCH 2/2] send-email: add support for --mailmap Jacob Keller
2024-08-16 23:41   ` Eric Sunshine
2024-08-16 23:49     ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cf58f786-06b0-4ad3-a6fd-f593af639c98@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=steadmon@google.com \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).