git-send-email getting filtered as spam by vger.kernel.org

git-send-email getting filtered as spam by vger.kernel.org

[Len Brown]

git-send-email is getting filtered by vger.kernel.org

git --version
git version 1.5.4.2.184.gb23b

Example rejected message below.
sent this way:

git-send-email --from "Len Brown <lenb@kernel.org>" --compose --to linux-acpi@vger.kernel.org  --smtp-server 192.168.0.6 --suppress-from --no-chain-reply-to patch-release

and then tried again with --chain-reply-to, but it also has not survived vger.kernel.org.

when it prompts "Message-ID to be used as In-Reply-To for the first email?"
I simply hit return, b/c I have no idea how to answer that question.

This has worked for me many times in the past, but seems to have broken recently.
I don't know if it was a change in git, or a change on vger.kernel.org.

clues?

thanks,
-Len

----------  Forwarded Message  ----------

Subject: Fw: TABOO linux-acpi@vger.kernel.org: global taboo header: m/<>/ global taboo header: m/<>/
Date: Thursday 21 February 2008 03:56
From: David Miller <davem@davemloft.net>
To: lenb@kernel.org
Cc: len.brown@intel.com


All of your postings to the mailing list bounced because of those "<>"
things in your headers.  We block that because it is a pattern
frequently used by spammers to cover up their Received headers.

...

Thanks.


-------------------------------------------------------
>From lenb@kernel.org Thu Feb 21 03:46:40 2008
Received: from mga09.intel.com ([134.134.136.24]:62635 "EHLO mga09.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1755925AbYBUIqc (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
        Thu, 21 Feb 2008 03:46:32 -0500
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
  by orsmga102.jf.intel.com with ESMTP; 21 Feb 2008 00:46:30 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.25,385,1199692800"; 
   d="scan'208";a="300482149"
Received: from unknown (HELO localhost.localdomain) ([10.127.56.36])
  by fmsmga002.fm.intel.com with ESMTP; 21 Feb 2008 00:44:45 -0800
From:   Len Brown <lenb@kernel.org>
To:     linux-acpi@vger.kernel.org
Cc:     Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
        Len Brown <len.brown@intel.com>
Subject: [PATCH 14/26] ACPI: thinkpad-acpi: make the video output feature optional
Date:   Thu, 21 Feb 2008 03:45:16 -0500
Message-Id: <d7c1d17dfed996e84212fc1ce617b2586dd70ec2.1203581638.git.len.brown@intel.com>
X-Mailer: git-send-email 1.5.4.2.184.gb23b
In-Reply-To: <>
References: <>
In-Reply-To: <208c70a45624400fafd7511b96bc426bf01f8f5e.1203581637.git.len.brown@intel.com>
References: <208c70a45624400fafd7511b96bc426bf01f8f5e.1203581637.git.len.brown@intel.com>
Organization: Intel Open Source Technology Center
Return-Path: <lenb@kernel.org>
X-Envelope-To: <"|/opt/Majordomo/wrapper resend -l linux-acpi -f x-linux-acpi -h vger.kernel.org linux-acpi-outgoing"> (uid 400)
X-Orcpt: rfc822;linux-acpi@vger.kernel.org
Original-Recipient: rfc822;linux-acpi@vger.kernel.org

From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>

The video output port control feature is not very useful on many ThinkPads
(especially when a X server is running), and lately userspace is getting
better and better at it, so it makes sense to allow users to stripe out the
thinkpad-acpi video feature from their kernels and save at least 2KB.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
---
 drivers/misc/Kconfig         |   17 +++++++++++++++++
 drivers/misc/thinkpad_acpi.c |   20 +++++++++++++-------
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1abc95c..982e27b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -258,6 +258,23 @@ config THINKPAD_ACPI_BAY
 
          If you are not sure, say Y here.
 
+config THINKPAD_ACPI_VIDEO
+       bool "Video output control support"
+       depends on THINKPAD_ACPI
+       default y
+       ---help---
+         Allows the thinkpad_acpi driver to provide an interface to control
+         the various video output ports.
+
+         This feature often won't work well, depending on ThinkPad model,
+         display state, video output devices in use, whether there is a X
+         server running, phase of the moon, and the current mood of
+         Schroedinger's cat.  If you can use X.org's RandR to control
+         your ThinkPad's video output ports instead of this feature,
+         don't think twice: do it and say N here to save some memory.
+
+         If you are not sure, say Y here.
+
 config THINKPAD_ACPI_HOTKEY_POLL
        bool "Suport NVRAM polling for hot keys"
        depends on THINKPAD_ACPI
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 02f9465..4ea3866 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -301,6 +301,13 @@ TPACPI_HANDLE(hkey, ec, "\\_SB.HKEY",      /* 600e/x, 770e, 770x */
           "HKEY",              /* all others */
           );                   /* 570 */
 
+TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA",  /* 570 */
+          "\\_SB.PCI0.AGP0.VID0",      /* 600e/x, 770x */
+          "\\_SB.PCI0.VID0",   /* 770e */
+          "\\_SB.PCI0.VID",    /* A21e, G4x, R50e, X30, X40 */
+          "\\_SB.PCI0.AGP.VID",        /* all others */
+          );                           /* R30, R31 */
+
 
 /*************************************************************************
  * ACPI helpers
@@ -2680,6 +2687,8 @@ static struct ibm_struct wan_driver_data = {
  * Video subdriver
  */
 
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
+
 enum video_access_mode {
        TPACPI_VIDEO_NONE = 0,
        TPACPI_VIDEO_570,       /* 570 */
@@ -2707,13 +2716,6 @@ static int video_orig_autosw;
 static int video_autosw_get(void);
 static int video_autosw_set(int enable);
 
-TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA",  /* 570 */
-          "\\_SB.PCI0.AGP0.VID0",      /* 600e/x, 770x */
-          "\\_SB.PCI0.VID0",   /* 770e */
-          "\\_SB.PCI0.VID",    /* A21e, G4x, R50e, X30, X40 */
-          "\\_SB.PCI0.AGP.VID",        /* all others */
-          );                           /* R30, R31 */
-
 TPACPI_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID");      /* G41 */
 
 static int __init video_init(struct ibm_init_struct *iibm)
@@ -3023,6 +3025,8 @@ static struct ibm_struct video_driver_data = {
        .exit = video_exit,
 };
 
+#endif /* CONFIG_THINKPAD_ACPI_VIDEO */
+
 /*************************************************************************
  * Light (thinklight) subdriver
  */
@@ -5807,10 +5811,12 @@ static struct ibm_init_struct ibms_init[] __initdata = {
                .init = wan_init,
                .data = &wan_driver_data,
        },
+#ifdef CONFIG_THINKPAD_ACPI_VIDEO
        {
                .init = video_init,
                .data = &video_driver_data,
        },
+#endif
        {
                .init = light_init,
                .data = &light_driver_data,
-- 
1.5.4.2.184.gb23b

Re: git-send-email getting filtered as spam by vger.kernel.org

[Len Brown]

It looks like the same patches formatted and set with git 1.5.4.2
made it through to the list.

-Len

On Thursday 21 February 2008 04:29, Len Brown wrote:
> git-send-email is getting filtered by vger.kernel.org
> 
> git --version
> git version 1.5.4.2.184.gb23b
> 
> Example rejected message below.
> sent this way:
> 
> git-send-email --from "Len Brown <lenb@kernel.org>" --compose --to linux-acpi@vger.kernel.org  --smtp-server 192.168.0.6 --suppress-from --no-chain-reply-to patch-release
> 
> and then tried again with --chain-reply-to, but it also has not survived vger.kernel.org.
> 
> when it prompts "Message-ID to be used as In-Reply-To for the first email?"
> I simply hit return, b/c I have no idea how to answer that question.
> 
> This has worked for me many times in the past, but seems to have broken recently.
> I don't know if it was a change in git, or a change on vger.kernel.org.
> 
> clues?
> 
> thanks,
> -Len
> 
> ----------  Forwarded Message  ----------
> 
> Subject: Fw: TABOO linux-acpi@vger.kernel.org: global taboo header: m/<>/ global taboo header: m/<>/
> Date: Thursday 21 February 2008 03:56
> From: David Miller <davem@davemloft.net>
> To: lenb@kernel.org
> Cc: len.brown@intel.com
> 
> 
> All of your postings to the mailing list bounced because of those "<>"
> things in your headers.  We block that because it is a pattern
> frequently used by spammers to cover up their Received headers.
> 
> ...
> 
> Thanks.
> 
> 
> -------------------------------------------------------
> >From lenb@kernel.org Thu Feb 21 03:46:40 2008
> Received: from mga09.intel.com ([134.134.136.24]:62635 "EHLO mga09.intel.com"
>         rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
>         id S1755925AbYBUIqc (ORCPT <rfc822;linux-acpi@vger.kernel.org>);
>         Thu, 21 Feb 2008 03:46:32 -0500
> Received: from fmsmga002.fm.intel.com ([10.253.24.26])
>   by orsmga102.jf.intel.com with ESMTP; 21 Feb 2008 00:46:30 -0800
> X-ExtLoop1: 1
> X-IronPort-AV: E=Sophos;i="4.25,385,1199692800"; 
>    d="scan'208";a="300482149"
> Received: from unknown (HELO localhost.localdomain) ([10.127.56.36])
>   by fmsmga002.fm.intel.com with ESMTP; 21 Feb 2008 00:44:45 -0800
> From:   Len Brown <lenb@kernel.org>
> To:     linux-acpi@vger.kernel.org
> Cc:     Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
>         Len Brown <len.brown@intel.com>
> Subject: [PATCH 14/26] ACPI: thinkpad-acpi: make the video output feature optional
> Date:   Thu, 21 Feb 2008 03:45:16 -0500
> Message-Id: <d7c1d17dfed996e84212fc1ce617b2586dd70ec2.1203581638.git.len.brown@intel.com>
> X-Mailer: git-send-email 1.5.4.2.184.gb23b
> In-Reply-To: <>
> References: <>
> In-Reply-To: <208c70a45624400fafd7511b96bc426bf01f8f5e.1203581637.git.len.brown@intel.com>
> References: <208c70a45624400fafd7511b96bc426bf01f8f5e.1203581637.git.len.brown@intel.com>
> Organization: Intel Open Source Technology Center
> Return-Path: <lenb@kernel.org>
> X-Envelope-To: <"|/opt/Majordomo/wrapper resend -l linux-acpi -f x-linux-acpi -h vger.kernel.org linux-acpi-outgoing"> (uid 400)
> X-Orcpt: rfc822;linux-acpi@vger.kernel.org
> Original-Recipient: rfc822;linux-acpi@vger.kernel.org
> 
> From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> 
> The video output port control feature is not very useful on many ThinkPads
> (especially when a X server is running), and lately userspace is getting
> better and better at it, so it makes sense to allow users to stripe out the
> thinkpad-acpi video feature from their kernels and save at least 2KB.
> 
> Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> Signed-off-by: Len Brown <len.brown@intel.com>
> ---
>  drivers/misc/Kconfig         |   17 +++++++++++++++++
>  drivers/misc/thinkpad_acpi.c |   20 +++++++++++++-------
>  2 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 1abc95c..982e27b 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -258,6 +258,23 @@ config THINKPAD_ACPI_BAY
>  
>           If you are not sure, say Y here.
>  
> +config THINKPAD_ACPI_VIDEO
> +       bool "Video output control support"
> +       depends on THINKPAD_ACPI
> +       default y
> +       ---help---
> +         Allows the thinkpad_acpi driver to provide an interface to control
> +         the various video output ports.
> +
> +         This feature often won't work well, depending on ThinkPad model,
> +         display state, video output devices in use, whether there is a X
> +         server running, phase of the moon, and the current mood of
> +         Schroedinger's cat.  If you can use X.org's RandR to control
> +         your ThinkPad's video output ports instead of this feature,
> +         don't think twice: do it and say N here to save some memory.
> +
> +         If you are not sure, say Y here.
> +
>  config THINKPAD_ACPI_HOTKEY_POLL
>         bool "Suport NVRAM polling for hot keys"
>         depends on THINKPAD_ACPI
> diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
> index 02f9465..4ea3866 100644
> --- a/drivers/misc/thinkpad_acpi.c
> +++ b/drivers/misc/thinkpad_acpi.c
> @@ -301,6 +301,13 @@ TPACPI_HANDLE(hkey, ec, "\\_SB.HKEY",      /* 600e/x, 770e, 770x */
>            "HKEY",              /* all others */
>            );                   /* 570 */
>  
> +TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA",  /* 570 */
> +          "\\_SB.PCI0.AGP0.VID0",      /* 600e/x, 770x */
> +          "\\_SB.PCI0.VID0",   /* 770e */
> +          "\\_SB.PCI0.VID",    /* A21e, G4x, R50e, X30, X40 */
> +          "\\_SB.PCI0.AGP.VID",        /* all others */
> +          );                           /* R30, R31 */
> +
>  
>  /*************************************************************************
>   * ACPI helpers
> @@ -2680,6 +2687,8 @@ static struct ibm_struct wan_driver_data = {
>   * Video subdriver
>   */
>  
> +#ifdef CONFIG_THINKPAD_ACPI_VIDEO
> +
>  enum video_access_mode {
>         TPACPI_VIDEO_NONE = 0,
>         TPACPI_VIDEO_570,       /* 570 */
> @@ -2707,13 +2716,6 @@ static int video_orig_autosw;
>  static int video_autosw_get(void);
>  static int video_autosw_set(int enable);
>  
> -TPACPI_HANDLE(vid, root, "\\_SB.PCI.AGP.VGA",  /* 570 */
> -          "\\_SB.PCI0.AGP0.VID0",      /* 600e/x, 770x */
> -          "\\_SB.PCI0.VID0",   /* 770e */
> -          "\\_SB.PCI0.VID",    /* A21e, G4x, R50e, X30, X40 */
> -          "\\_SB.PCI0.AGP.VID",        /* all others */
> -          );                           /* R30, R31 */
> -
>  TPACPI_HANDLE(vid2, root, "\\_SB.PCI0.AGPB.VID");      /* G41 */
>  
>  static int __init video_init(struct ibm_init_struct *iibm)
> @@ -3023,6 +3025,8 @@ static struct ibm_struct video_driver_data = {
>         .exit = video_exit,
>  };
>  
> +#endif /* CONFIG_THINKPAD_ACPI_VIDEO */
> +
>  /*************************************************************************
>   * Light (thinklight) subdriver
>   */
> @@ -5807,10 +5811,12 @@ static struct ibm_init_struct ibms_init[] __initdata = {
>                 .init = wan_init,
>                 .data = &wan_driver_data,
>         },
> +#ifdef CONFIG_THINKPAD_ACPI_VIDEO
>         {
>                 .init = video_init,
>                 .data = &video_driver_data,
>         },
> +#endif
>         {
>                 .init = light_init,
>                 .data = &light_driver_data,

Re: git-send-email getting filtered as spam by vger.kernel.org

[Uwe Kleine-König]

Len Brown wrote:
> It looks like the same patches formatted and set with git 1.5.4.2
> made it through to the list.
I suspect 1ca3d6ed01774eab37e96d9c88b840ea618f97af.

Best regards
Uwe

-- 
Uwe Kleine-König

Re: git-send-email getting filtered as spam by vger.kernel.org

[Junio C Hamano]

Uwe Kleine-König  <ukleinek@informatik.uni-freiburg.de> writes:

> Len Brown wrote:
>> It looks like the same patches formatted and set with git 1.5.4.2
>> made it through to the list.
> I suspect 1ca3d6ed01774eab37e96d9c88b840ea618f97af.

When you talk about commits, please also add the summary line,
like this [*1*]:

    1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")

Len said he has the issue with v1.5.4.2-184-gb23b27e but not
with v1.5.4.2.

    $ git lg v1.5.4.2..b23b27e -- git-send-email.perl
    1ca3d6e... send-email: squelch warning due to comparing undefined $_ to ""
    6564828... git-send-email: Generalize auto-cc recipient mechanism.
    8a7c56e... git-send-email: Better handling of EOF
    8742997... git-send-email: SIG{TERM,INT} handlers
    2363d74... git-send-email: ssh/login style password requests

and I think you are right.  I see In-reply-to: <> in the reject
message.

Perhaps we should fix it up like this...


diff --git a/git-send-email.perl b/git-send-email.perl
index ccb87a2..c9f8c6b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -475,7 +475,7 @@ if ($thread && !defined $initial_reply_to && $prompting) {
 
 	$initial_reply_to = $_;
 }
-if (defined $initial_reply_to) {
+if (defined $initial_reply_to && $initial_reply_to ne '') {
 	$initial_reply_to =~ s/^\s*<?/</;
 	$initial_reply_to =~ s/>?\s*$/>/;
 }



[Footnote]

*1* Here is what I have in $HOME/.gitconfig to allow me to say
"git one 1ca3d6ed0177".

[alias]
	lg = log --pretty=oneline --abbrev-commit
	one = show -s --pretty='format:%h (%s)'

Re: git-send-email getting filtered as spam by vger.kernel.org

[Mike Hommey]

On Thu, Feb 21, 2008 at 01:14:19PM -0800, Junio C Hamano wrote:
> Uwe Kleine-König  <ukleinek@informatik.uni-freiburg.de> writes:
> 
> > Len Brown wrote:
> >> It looks like the same patches formatted and set with git 1.5.4.2
> >> made it through to the list.
> > I suspect 1ca3d6ed01774eab37e96d9c88b840ea618f97af.
> 
> When you talk about commits, please also add the summary line,
> like this [*1*]:
> 
>     1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")
> 
> Len said he has the issue with v1.5.4.2-184-gb23b27e but not
> with v1.5.4.2.
> 
>     $ git lg v1.5.4.2..b23b27e -- git-send-email.perl
>     1ca3d6e... send-email: squelch warning due to comparing undefined $_ to ""
>     6564828... git-send-email: Generalize auto-cc recipient mechanism.
>     8a7c56e... git-send-email: Better handling of EOF
>     8742997... git-send-email: SIG{TERM,INT} handlers
>     2363d74... git-send-email: ssh/login style password requests
> 
> and I think you are right.  I see In-reply-to: <> in the reject
> message.
> 
> Perhaps we should fix it up like this...
(...)

And perhaps add a test, because it's not the first time the issue is
discussed http://kerneltrap.org/mailarchive/git/2007/12/11/488243 ;)

Mike

Re: git-send-email getting filtered as spam by vger.kernel.org

[Jay Soffian]

On Thu, Feb 21, 2008 at 4:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
>  Perhaps we should fix it up like this...

Doh, my bad...

>  diff --git a/git-send-email.perl b/git-send-email.perl
>  index ccb87a2..c9f8c6b 100755
>  --- a/git-send-email.perl
>  +++ b/git-send-email.perl
>  @@ -475,7 +475,7 @@ if ($thread && !defined $initial_reply_to && $prompting) {
>
>         $initial_reply_to = $_;
>   }
>  -if (defined $initial_reply_to) {
>  +if (defined $initial_reply_to && $initial_reply_to ne '') {
>         $initial_reply_to =~ s/^\s*<?/</;
>         $initial_reply_to =~ s/>?\s*$/>/;
>   }

Actually:

if ($initial_reply_to) { ...

should be all that's needed.

j.

Re: git-send-email getting filtered as spam by vger.kernel.org

[Mike Hommey]

On Thu, Feb 21, 2008 at 04:41:08PM -0500, Jay Soffian wrote:
> On Thu, Feb 21, 2008 at 4:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >  Perhaps we should fix it up like this...
> 
> Doh, my bad...
> 
> >  diff --git a/git-send-email.perl b/git-send-email.perl
> >  index ccb87a2..c9f8c6b 100755
> >  --- a/git-send-email.perl
> >  +++ b/git-send-email.perl
> >  @@ -475,7 +475,7 @@ if ($thread && !defined $initial_reply_to && $prompting) {
> >
> >         $initial_reply_to = $_;
> >   }
> >  -if (defined $initial_reply_to) {
> >  +if (defined $initial_reply_to && $initial_reply_to ne '') {
> >         $initial_reply_to =~ s/^\s*<?/</;
> >         $initial_reply_to =~ s/>?\s*$/>/;
> >   }
> 
> Actually:
> 
> if ($initial_reply_to) { ...
> 
> should be all that's needed.

And reminds me something ;)
http://kerneltrap.org/mailarchive/git/2007/12/11/488177

Mike

Re: git-send-email getting filtered as spam by vger.kernel.org

[Jay Soffian]

On Thu, Feb 21, 2008 at 4:49 PM, Mike Hommey <mh@glandium.org> wrote:
>  And reminds me something ;)
>  http://kerneltrap.org/mailarchive/git/2007/12/11/488177

Okay, I'll contribute a patch with a test case since I broke it (this time...).

j.

Re: git-send-email getting filtered as spam by vger.kernel.org

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> And reminds me something ;)
> http://kerneltrap.org/mailarchive/git/2007/12/11/488177

Although I admit I try to be less picky about what I am not a
heavy user of, I do not want to be deliberately sloppy by saying
"if ($var)" in Perl when $var is an end-user string (i.e. could
be "0").

Yes, it is unlikely the user mistypes "0" when asked for a
message Id, but it is just a matter of principle...
 

[PATCH] send-email: fix In-Reply-To regression

[Jay Soffian]

Fix a regression introduced by

1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")

where if the user was prompted for an initial In-Reply-To and didn't
provide one, messages would be sent out with an invalid In-Reply-To of
"<>"

Also add test cases for the regression and the fix. A small modification
was needed to allow send-email to take its replies from stdin if the
environment variable GIT_SEND_EMAIL_NOTTY is set.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---

An issue cropped up with testing the regression: it only occured if
initial_reply_to was "", and the only way to do that is to respond to
the Initial-Reply-To prompt with "\n". But send-email uses readline,
which insists on /dev/tty.

So, I initially simulated the breakage by using --initial-reply-to=" ",
but this isn't quite the same thing. However, it turns out this can also
cause an invalid In-Reply-To, which wasn't fixed by Junio's suggestion
of checking that initial_reply_to ne "". So I did a slightly different
fix that handles initial_reply_to eq  " ".

Anyway, back to testing the original problem. I didn't want to use
expect or Expect.pm, so I made a small change to send-email where if
GIT_SEND_EMAIL_NOTTY is set, it will read from stdin instead of
/dev/tty.

But, I wonder if in the future we'll want to enhance the testing
framework to be able to do expect-type stuff?

j.

 git-send-email.perl   |    9 ++++++---
 t/t9001-send-email.sh |   21 +++++++++++++++++++++
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index ccb87a2..29b1105 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -170,7 +170,9 @@ my $envelope_sender;
 
 my $repo = Git->repository();
 my $term = eval {
-	new Term::ReadLine 'git-send-email';
+	$ENV{"GIT_SEND_EMAIL_NOTTY"}
+		? new Term::ReadLine 'git-send-email', \*STDIN, \*STDOUT
+		: new Term::ReadLine 'git-send-email';
 };
 if ($@) {
 	$term = new FakeTerm "$@: going non-interactive";
@@ -476,8 +478,9 @@ if ($thread && !defined $initial_reply_to && $prompting) {
 	$initial_reply_to = $_;
 }
 if (defined $initial_reply_to) {
-	$initial_reply_to =~ s/^\s*<?/</;
-	$initial_reply_to =~ s/>?\s*$/>/;
+	$initial_reply_to =~ s/^\s*<?//;
+	$initial_reply_to =~ s/>?\s*$//;
+	$initial_reply_to = "<$initial_reply_to>" if $initial_reply_to ne '';
 }
 
 if (!defined $smtp_server) {
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 08f7c3d..1422e9f 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -108,4 +108,25 @@ test_expect_success 'allow long lines with --no-validate' '
 		2>errors
 '
 
+test_expect_failure 'Invalid In-Reply-To' '
+	git send-email \
+		--from="Example <nobody@example.com>" \
+		--to=nobody@example.com \
+		--in-reply-to=" " \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		$patches
+		2>errors
+	! grep "^In-Reply-To: < *>" msgtxt
+'
+
+test_expect_success 'Valid In-Reply-To when prompting' '
+	(echo "From Example <from@example.com>"
+	 echo "To Example <to@example.com>"
+	 echo ""
+	) | env GIT_SEND_EMAIL_NOTTY=1 git send-email \
+		--smtp-server="$(pwd)/fake.sendmail" \
+		$patches 2>errors &&
+	! grep "^In-Reply-To: < *>" msgtxt
+'
+
 test_done
-- 
1.5.4.2.236.g77b4.dirty

Re: [PATCH] send-email: fix In-Reply-To regression

[Junio C Hamano]

The patch looked Ok with my initial cursory review.  Success
reports with Tested-by: would be appreciated.

Re: git-send-email getting filtered as spam by vger.kernel.org

[Len Brown]

On Thursday 21 February 2008 07:21, Len Brown wrote:
> It looks like the same patches formatted and set with git 1.5.4.2
> made it through to the list.
> 
> -Len
> 
> On Thursday 21 February 2008 04:29, Len Brown wrote:
> > git-send-email is getting filtered by vger.kernel.org
> > 
> > git --version
> > git version 1.5.4.2.184.gb23b
> > 

The top of tree,
git version 1.5.4.2.197.g22c43
is working.

thanks for the quick response.
-Len

Re: [PATCH] send-email: fix In-Reply-To regression

[Uwe Kleine-König]

Hello Junio,

Junio C Hamano wrote:
> The patch looked Ok with my initial cursory review.  Success
> reports with Tested-by: would be appreciated.
I see you took the patch as 

	0fb7fc7... send-email: fix In-Reply-To regression

.  Do you consider adding it to your maint branch?

Best regards
Uwe

-- 
Uwe Kleine-König

Re: [PATCH] send-email: fix In-Reply-To regression

[Junio C Hamano]

Uwe Kleine-König  <ukleinek@informatik.uni-freiburg.de> writes:

> I see you took the patch as 
>
> 	0fb7fc7... send-email: fix In-Reply-To regression
>
> .  Do you consider adding it to your maint branch?

Thanks for a reminder.  Done.