Re: [RFC] send-email aliases when editing patches or using --xx-cmd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 4, 2015 at 6:53 PM, Remi Lespinet
<remi.lespinet@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, Jun 4, 2015 at 1:17 PM, Remi LESPINET
> <remi.lespinet@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> Working on git-send-email, I've seen that there's no aliases support
>> when manually adding a recipient in a 'To' or 'Cc' field in a patch
>> and for the --to-cmd and --cc-cmd.
>>
>> I would like to add this support, and I wonder if there are reasons
>> not to do it.
>>
>> Thanks.
>
> I just realize that I totally messed up, Of course I don't want to add
> To or Cc fields to patches.
>
> In fact I want to add aliases support for --to-cmd and --cc-cmd options.
> But the modification depends on wheter we can use aliases in fields
> used by send-email (such as author or signoff-by..) when manually
> editing a patch or not.
>
> Sorry for this mistake :(

You are right that Signed-off-by: myAlias wouldn't make sense, but is
that really what you intended to propose?  It's definitely not a good
idea to write patches that way, but on the other hand, if git happens
to accept an alias there, what's the harm?  Git will send an email...
the patch will be rejected.

Also, I believe git-send-email looks for signed-off-by, regardless of
the presence or output of to-cmd (around line 1490 -- "Now parse the
message body").

Something like to-cmd is much more general than just looking for
Signed-off-by, etc, or scanning a patch for things that look like
email addresses.  The to-cmd can also look for keywords in the patch,
like component names, and return an array of maintainer email
addresses for those components, for instance.  It might be the case
that none of the emails returned by the to-cmd are actually ever
explicitly mentioned in the patch.  In my workspace, I might indeed
write a script, specify it as the to-cmd, and have the script return
an array of email addresses according to whatever criteria I can
imagine.  What's the harm if, in my script, in my own workspace, I
return an array of email aliases in the to_cmd, instead?

Now, as long as the to-cmd is already a script, executed by the
computer, there's really very little to gain in using email aliases
versus whole email addresses.  A script can emit a whole properly
formatted email address just as easily as it can emit an email alias.

Your proposal is just a different use for email aliases, which is
independent from where the aliases come from.  There is no conflict
with any of the email alias parsers.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]