git send-email prompting too much

git send-email prompting too much

[Dan McGee]

I'm guessing this is related to commit
6e1825186bd052fc1f77b7c8c9a31fbb9a67d90c but I haven't bisected yet.
Having to hit enter 10 times ad the Message-ID prompt seemed a bit odd
to me. Has anyone else seen this behavior?

dmcgee@galway ~/projects/git (working)
$ git send-email 000*
0001-git-repack-use-non-dashed-update-server-info.patch
0002-pack-objects-report-actual-number-of-threads-to-be.patch
Who should the emails appear to be from? [Dan McGee <dpmcgee@gmail.com>]
Emails will be sent from: Dan McGee <dpmcgee@gmail.com>
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
Message-ID to be used as In-Reply-To for the first email?
(mbox) Adding cc: Dan McGee <dpmcgee@gmail.com> from line 'From: Dan
McGee <dpmcgee@gmail.com>'
(body) Adding cc: Dan McGee <dpmcgee@gmail.com> from line
'Signed-off-by: Dan McGee <dpmcgee@gmail.com>'

From: Dan McGee <dpmcgee@gmail.com>
To: git@vger.kernel.org
Cc: Dan McGee <dpmcgee@gmail.com>
Subject: [PATCH 1/2] git-repack: use non-dashed update-server-info
Date: Sat,  4 Apr 2009 11:59:55 -0500
Message-Id: <1238864396-8964-1-git-send-email-dpmcgee@gmail.com>
X-Mailer: git-send-email 1.6.2.2.404.ge96f3.dirty

    The Cc list above has been expanded by additional
    addresses found in the patch commit message. By default
    send-email prompts before sending whenever this occurs.
    This behavior is controlled by the sendemail.confirm
    configuration setting.

    For additional information, run 'git send-email --help'.
    To retain the current behavior, but squelch this message,
    run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[q]uit|[a]ll): a
OK. Log says:
Sendmail: /usr/bin/msmtp -i git@vger.kernel.org dpmcgee@gmail.com
From: Dan McGee <dpmcgee@gmail.com>
To: git@vger.kernel.org
Cc: Dan McGee <dpmcgee@gmail.com>
Subject: [PATCH 1/2] git-repack: use non-dashed update-server-info
Date: Sat,  4 Apr 2009 11:59:55 -0500
Message-Id: <1238864396-8964-1-git-send-email-dpmcgee@gmail.com>
X-Mailer: git-send-email 1.6.2.2.404.ge96f3.dirty

Result: OK
(mbox) Adding cc: Dan McGee <dpmcgee@gmail.com> from line 'From: Dan
McGee <dpmcgee@gmail.com>'
(body) Adding cc: Dan McGee <dpmcgee@gmail.com> from line
'Signed-off-by: Dan McGee <dpmcgee@gmail.com>'
OK. Log says:
Sendmail: /usr/bin/msmtp -i git@vger.kernel.org dpmcgee@gmail.com
From: Dan McGee <dpmcgee@gmail.com>
To: git@vger.kernel.org
Cc: Dan McGee <dpmcgee@gmail.com>
Subject: [PATCH 2/2] pack-objects: report actual number of threads to be used
Date: Sat,  4 Apr 2009 11:59:56 -0500
Message-Id: <1238864396-8964-2-git-send-email-dpmcgee@gmail.com>
X-Mailer: git-send-email 1.6.2.2.404.ge96f3.dirty
In-Reply-To: <1238864396-8964-1-git-send-email-dpmcgee@gmail.com>
References: <1238864396-8964-1-git-send-email-dpmcgee@gmail.com>

Result: OK

Re: git send-email prompting too much

[Bruce Stephens]

Dan McGee <dpmcgee@gmail.com> writes:

> I'm guessing this is related to commit
> 6e1825186bd052fc1f77b7c8c9a31fbb9a67d90c but I haven't bisected yet.
> Having to hit enter 10 times ad the Message-ID prompt seemed a bit odd
> to me. Has anyone else seen this behavior?

Yes.  Apparently one uses \C-d now.

[...]

Re: git send-email prompting too much

[Jay Soffian]

On Sat, Apr 4, 2009 at 1:12 PM, Bruce Stephens <bruce.stephens@isode.com> wrote:
> Dan McGee <dpmcgee@gmail.com> writes:
>
>> I'm guessing this is related to commit
>> 6e1825186bd052fc1f77b7c8c9a31fbb9a67d90c but I haven't bisected yet.
>> Having to hit enter 10 times ad the Message-ID prompt seemed a bit odd
>> to me. Has anyone else seen this behavior?
>
> Yes.  Apparently one uses \C-d now.

Wait. Did hitting just enter work in the past? Because I tested this
before I made this commit and at least on my machine, hitting enter
just presented the prompt again. So I retained that behavior.

I looked over the Term::ReadLine code and I don't see how just hitting
return ever worked. But if you tell me it did, I believe that and I
can restore that behavior.

Out of curiosity, what is your OS and version, perl version, and what
does does perl -e 'use Term::ReadLine; print
"$Term::ReadLine::VERSION\n"' return?

Thanks,

j.

Re: git send-email prompting too much

[Jay Soffian]

On Sat, Apr 4, 2009 at 10:13 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Wait. Did hitting just enter work in the past? Because I tested this
> before I made this commit and at least on my machine, hitting enter
> just presented the prompt again. So I retained that behavior.

Argh. I should read my own commit message. I claim:

    2) "Who should the emails be sent to?". Previously this prompt passed a
    second argument ("") to $term->readline() which was ignored. I believe
    the intent was to allow the user to just hit return. Now the user
    can do so, or type ctrl-d.

    3) "Message-ID to be used as In-Reply-To for the first email?".
    Previously this prompt passed a second argument (effectively undef) to
    $term->readline() which was ignored. I believe the intent was the same
    as for (2), to allow the user to just hit return. Now the user can do
    so, or type ctrl-d.

Clearly I broke something. Will send a patch shortly. :-(

j.

Re: git send-email prompting too much

[Junio C Hamano]

Thanks.

[PATCH] send-email: fix nasty bug in ask() function

[Jay Soffian]

Commit 6e18251 (send-email: refactor and ensure prompting doesn't loop
forever) introduced an ask function, which unfortunately had a nasty
bug. This caused it not to accept anything but the default reply to the
"Who should the emails appear to be from?" prompt, and nothing but
ctrl-d to the "Who should the emails be sent to?" and "Message-ID to be
used as In-Reply-To for the first email?" prompts.

This commit corrects the issues and adds a test to confirm the fix.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
On Sat, Apr 4, 2009 at 1:02 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> I'm guessing this is related to commit
> 6e1825186bd052fc1f77b7c8c9a31fbb9a67d90c but I haven't bisected yet.
> Having to hit enter 10 times ad the Message-ID prompt seemed a bit odd
> to me. Has anyone else seen this behavior?
>
> dmcgee@galway ~/projects/git (working)
> $ git send-email 000*
> 0001-git-repack-use-non-dashed-update-server-info.patch
> 0002-pack-objects-report-actual-number-of-threads-to-be.patch
> Who should the emails appear to be from? [Dan McGee <dpmcgee@gmail.com>]
> Emails will be sent from: Dan McGee <dpmcgee@gmail.com>
> Message-ID to be used as In-Reply-To for the first email?
> Message-ID to be used as In-Reply-To for the first email?

I really apologize for this breakage. This patch should fix the issue.
I'm quite surprised that there wasn't already a test for the prompting,
but shame on me for not double-checking before refactoring.

I'm also super confused why the issue is occuring. You can see from the
patch below that by default the ask() function attempted to match the
user's input against the empty regex //, which should match anything:

$ perl -e 'use strict; my $resp="something"; my $re=""; print "true\n" if $resp =~ /$re/'
true
$ perl -e 'use strict; my $resp=""; my $re=""; print "true\n" if $resp =~ /$re/'
true

Any yet while my demonstration above works as I expect, for some reason
what is basically the same code (AFAICT) in send-email does not match. I
thought I knew my perl fairly well, but maybe some perl guru can see
what's going wrong.

 git-send-email.perl   |    4 ++--
 t/t9001-send-email.sh |   13 +++++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 6bbdfec..172b53c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -608,7 +608,7 @@ EOT
 
 sub ask {
 	my ($prompt, %arg) = @_;
-	my $valid_re = $arg{valid_re} || ""; # "" matches anything
+	my $valid_re = $arg{valid_re};
 	my $default = $arg{default};
 	my $resp;
 	my $i = 0;
@@ -624,7 +624,7 @@ sub ask {
 		if ($resp eq '' and defined $default) {
 			return $default;
 		}
-		if ($resp =~ /$valid_re/) {
+		if (!defined $valid_re or $resp =~ /$valid_re/) {
 			return $resp;
 		}
 	}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 192b97b..3c90c4f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -130,6 +130,19 @@ test_expect_success 'Show all headers' '
 	test_cmp expected-show-all-headers actual-show-all-headers
 '
 
+test_expect_success 'Prompting works' '
+	clean_fake_sendmail &&
+	(echo "Example <from@example.com>"
+	 echo "to@example.com"
+	 echo ""
+	) | GIT_SEND_EMAIL_NOTTY=1 git send-email \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		$patches \
+		2>errors &&
+		grep "^From: Example <from@example.com>$" msgtxt1 &&
+		grep "^To: to@example.com$" msgtxt1
+'
+
 z8=zzzzzzzz
 z64=$z8$z8$z8$z8$z8$z8$z8$z8
 z512=$z64$z64$z64$z64$z64$z64$z64$z64
-- 
1.6.2.2.405.g6d8cc4

Re: [PATCH] send-email: fix nasty bug in ask() function

[Jay Soffian]

> I'm also super confused why the issue is occuring. You can see from the
> patch below that by default the ask() function attempted to match the
> user's input against the empty regex //, which should match anything:
>
> $ perl -e 'use strict; my $resp="something"; my $re=""; print "true\n" if $resp =~ /$re/'
> true
> $ perl -e 'use strict; my $resp=""; my $re=""; print "true\n" if $resp =~ /$re/'
> true
>
> Any yet while my demonstration above works as I expect, for some reason
> what is basically the same code (AFAICT) in send-email does not match. I
> thought I knew my perl fairly well, but maybe some perl guru can see
> what's going wrong.

Ah, found it in perlreref:

   If 'pattern' is an empty string, the last successfully matched
   regex is used.

Grumble.

j.