threads / discuss / 18716

git send-email prompting too much

Subject: git send-email prompting too much

## tl;dr

7 messages between Apr 4, 2009 and Apr 5, 2009.

replies: 6people: 4as markdown or json

Dan McGee· Apr 4, 2009, 17:02 UTC · lore

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
Bruce Stephens· Apr 4, 2009, 17:12 UTC · re: Dan McGee · lore

Re: git send-email prompting too much

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.
[...]
Jay Soffian· Apr 5, 2009, 02:13 UTC · re: Bruce Stephens · lore

Re: git send-email prompting too much

On Sat, Apr 4, 2009 at 1:12 PM, Bruce Stephens <bruce.stephens@isode.com> wrote:
Show 8 quoted lines
> 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.
Jay Soffian· Apr 5, 2009, 02:49 UTC · re: Jay Soffian · lore

Re: git send-email prompting too much

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.
Jay Soffian· Apr 5, 2009, 03:23 UTC · re: Dan McGee · lore

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

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:
Show 13 quoted lines
> 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
Jay Soffian· Apr 5, 2009, 03:31 UTC · re: Jay Soffian · lore

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

Show 13 quoted lines
> 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.

← back to recent threads