git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] git-send-email.perl: implement suggestions made by perlcritic
Date: Thu, 21 Mar 2013 22:21:38 +0530	[thread overview]
Message-ID: <CALkWK0kkWAkiANL-vL-OthKSDkoU2b_Q68frkGc06QNG7RbSFQ@mail.gmail.com> (raw)
In-Reply-To: <7vd2usbwkn.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index be809e5..e974b11 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -513,7 +513,7 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
>>  ($sender) = expand_aliases($sender) if defined $sender;
>>
>>  # returns 1 if the conflict must be solved using it as a format-patch argument
>> -sub check_file_rev_conflict($) {
>> +sub check_file_rev_conflict {
>
> Have you verified that the callers of this sub are OK with this
> change?  It used to force scalar context on its arguments but now it
> does not.
>
> I am not saying I know the callers will get broken.  I am trying to
> make sure that this is *not* the result of blindly following
> perlcritic output without understanding the ramifications of the
> change.

No Junio, I haven't blindly followed the perlcritic output.  I've
considered the ramifications, audited the callers, and run the tests
to make sure that nothing breaks.

>> @@ -1438,7 +1438,7 @@ sub recipients_cmd {
>>
>>       my $sanitized_sender = sanitize_address($sender);
>>       my @addresses = ();
>> -     open my $fh, "$cmd \Q$file\E |"
>> +     open my $fh, q{-|}, "$cmd \Q$file\E"
>
> Strange quoting (why not just say "-|"?) aside

Intentional.  I thought it was a pretty way to differentiate between a
mode string (which can only be <, >, or -|) and a filename string.  If
you don't share my taste, feel free to use quotes instead.

> , if you are moving
> away from the two-param form of open(), it would be a sane thing to
> do to also stop concatenating the arguments to commands to avoid
> shell metacharacter gotcha.  It will make the resulting code much
> safer.

Yes, the file can be improved in many ways, but that is not the topic
of this series.  This series just makes the changes suggested by
perlcritic gentle.

  reply	other threads:[~2013-03-21 16:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 12:39 [PATCH] git-send-email.perl: implement suggestions made by perlcritic Ramkumar Ramachandra
2013-03-21 15:29 ` Junio C Hamano
2013-03-21 16:51   ` Ramkumar Ramachandra [this message]
2013-03-27 17:13     ` Ramkumar Ramachandra
2013-03-27 17:38       ` Junio C Hamano
2013-03-28 12:47         ` [PATCH v2] " Ramkumar Ramachandra
2013-03-28 18:57           ` Jonathan Nieder
2013-03-28 20:26           ` Junio C Hamano
2013-03-31 20:59             ` Ramkumar Ramachandra
2013-04-01  1:39               ` Junio C Hamano
2013-04-01  1:40                 ` [PATCH 1/3] send-email: use "return;" not "return undef;" on error codepaths Junio C Hamano
2013-04-01  1:40                   ` [PATCH 2/3] send-email: drop misleading function prototype Junio C Hamano
2013-04-01  2:20                     ` Jonathan Nieder
2013-04-01  4:09                     ` Eric Sunshine
2013-04-01  1:40                   ` [PATCH 3/3] send-email: use the three-arg form of open in recipients_cmd Junio C Hamano
2013-04-01  2:30                     ` Jonathan Nieder
2013-04-02  7:46                     ` Ramkumar Ramachandra
2013-04-01  4:08                   ` [PATCH 1/3] send-email: use "return;" not "return undef;" on error codepaths Eric Sunshine
2013-04-02  7:59                   ` Ramkumar Ramachandra
2013-04-02 14:49                     ` Junio C Hamano
2013-04-02  7:41                 ` [PATCH v2] git-send-email.perl: implement suggestions made by perlcritic Ramkumar Ramachandra

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=CALkWK0kkWAkiANL-vL-OthKSDkoU2b_Q68frkGc06QNG7RbSFQ@mail.gmail.com \
    --to=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).