[PATCH] Added --export option to git-send-email.

[PATCH] Added --export option to git-send-email.

[Eduard - Gabriel Munteanu]

This option allows the user to process patches with git-send-email and then
import them into an email client, without having to send them directly. The
output format is mbox.

Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
 Documentation/git-send-email.txt |    6 ++++++
 git-send-email.perl              |   19 +++++++++++++++++++
 2 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index afbb294..17a59dd 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -73,6 +73,12 @@ The --cc option must be repeated for each user you want on the cc list.
         Default is the value of 'sendemail.signedoffcc' configuration value;
         if that is unspecified, default to --signed-off-by-cc.
 
+--export::
+	Do not send anything, just export the emails in mbox format. You can
+	use this if you need to import the messages into your email client,
+	for example. Overwrites the target, which must not be one of the
+	input files.
+
 --quiet::
 	Make git-send-email less verbose.  One line per email should be
 	all that is output.
diff --git a/git-send-email.perl b/git-send-email.perl
index 3564419..53539cf 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -100,6 +100,9 @@ Options:
    --thread       Specify that the "In-Reply-To:" header should be set on all
                   emails. Defaults to on.
 
+   --export	  Don't actually send emails, just export them to a mbox file.
+		  Overwrites target, which must not be one of the input files.
+
    --quiet	  Make git-send-email less verbose.  One line per email
                   should be all that is output.
 
@@ -184,6 +187,7 @@ if ($@) {
 
 # Behavior modification variables
 my ($quiet, $dry_run) = (0, 0);
+my ($export_file);
 
 # Variables with corresponding config settings
 my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
@@ -260,6 +264,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
 		    "suppress-from!" => \$suppress_from,
 		    "suppress-cc=s" => \@suppress_cc,
 		    "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+		    "export=s" => \$export_file,
 		    "dry-run" => \$dry_run,
 		    "envelope-sender=s" => \$envelope_sender,
 		    "thread!" => \$thread,
@@ -691,6 +696,7 @@ sub sanitize_address
 
 }
 
+my ($out);
 sub send_message
 {
 	my @recipients = unique_email_list(@to);
@@ -741,6 +747,10 @@ X-Mailer: git-send-email $gitversion
 
 	if ($dry_run) {
 		# We don't want to send the email.
+	} elsif (defined $export_file) {
+		my $mbox_from = "From $raw_from $date";
+		$message =~ s/^(>{0,})From/>$1From/m;
+		print $out "$mbox_from\n$header\n$message";
 	} elsif ($smtp_server =~ m#^/#) {
 		my $pid = open my $sm, '|-';
 		defined $pid or die $!;
@@ -835,6 +845,11 @@ $reply_to = $initial_reply_to;
 $references = $initial_reply_to || '';
 $subject = $initial_subject;
 
+if (defined $export_file) {
+	my $err = open $out, '>', $export_file;
+	defined $err or die "Can't open '$export_file': $!";
+}
+
 foreach my $t (@files) {
 	open(F,"<",$t) or die "can't open file $t";
 
@@ -979,6 +994,10 @@ foreach my $t (@files) {
 	$message_id = undef;
 }
 
+if (defined $export_file) {
+	close $out or warn $?;
+}
+
 if ($compose) {
 	cleanup_compose_files();
 }
-- 
1.5.6.1

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:

> This option allows the user to process patches with git-send-email and then
> import them into an email client, without having to send them directly. The
> output format is mbox.

Input format is also mbox, so an obvious question is "why?"

Re: [PATCH] Added --export option to git-send-email.

[Eduard - Gabriel Munteanu]

On Fri, 11 Jul 2008 00:03:06 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
> 
> > This option allows the user to process patches with git-send-email
> > and then import them into an email client, without having to send
> > them directly. The output format is mbox.
> 
> Input format is also mbox, so an obvious question is "why?"

Hi,

git-send-email has a lot more mail processing power than
git-format-patch. For example, there is no way to fill in "To:" with
git-format-patch.

I use this because I want to send the emails with my mail client
(Claws-Mail), not directly. This allows me to use git-send-email to
process patches instead of kludging the headers with something like
formail.


	Eduard

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:

> diff --git a/git-send-email.perl b/git-send-email.perl
> index 3564419..53539cf 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -741,6 +747,10 @@ X-Mailer: git-send-email $gitversion
>  
>  	if ($dry_run) {
>  		# We don't want to send the email.
> +	} elsif (defined $export_file) {
> +		my $mbox_from = "From $raw_from $date";
> +		$message =~ s/^(>{0,})From/>$1From/m;
> +		print $out "$mbox_from\n$header\n$message";

Sorry, but I am scratching my head here.  Shouldn't this "bare From
munging" be like this instead?

		$message =~ s/^From />From /m;

Re: [PATCH] Added --export option to git-send-email.

[Avery Pennarun]

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>  > +     } elsif (defined $export_file) {
>  > +             my $mbox_from = "From $raw_from $date";
>  > +             $message =~ s/^(>{0,})From/>$1From/m;
>  > +             print $out "$mbox_from\n$header\n$message";
>
> Sorry, but I am scratching my head here.  Shouldn't this "bare From
>  munging" be like this instead?
>
>                 $message =~ s/^From />From /m;

That wouldn't be a reversible operation.

Have fun,

Avery

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

"Avery Pennarun" <apenwarr@gmail.com> writes:

> On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
>> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>>  > +     } elsif (defined $export_file) {
>>  > +             my $mbox_from = "From $raw_from $date";
>>  > +             $message =~ s/^(>{0,})From/>$1From/m;
>>  > +             print $out "$mbox_from\n$header\n$message";
>>
>> Sorry, but I am scratching my head here.  Shouldn't this "bare From
>>  munging" be like this instead?
>>
>>                 $message =~ s/^From />From /m;
>
> That wouldn't be a reversible operation.

So what?  Adding Cc: and stuff send-email does are already irreversible
anyway.

Re: [PATCH] Added --export option to git-send-email.

[Avery Pennarun]

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
>  >> Sorry, but I am scratching my head here.  Shouldn't this "bare From
>  >>  munging" be like this instead?
>  >>
>  >>                 $message =~ s/^From />From /m;
>  >
>  > That wouldn't be a reversible operation.
>
> So what?  Adding Cc: and stuff send-email does are already irreversible
>  anyway.

At one point the people who write mailers realized that just munging
"From" to ">From" when putting things into an mbox was irreversible,
ie, there was no way to later display the contents of the mbox without
showing ">From" where "From" was intended.

However, if you always insert _another_ ">" whenever "^>*From" is
detected, then you can also always do the opposite upon displaying to
the user, and the message is effectively not munged.  It becomes
simply a part of the mbox file encoding.

So by encoding it this way, someone with a modern mailer could view
the resulting mbox with all the munged text de-mungled.  Someone
without a modern mailer would see munging anyhow, so they're no worse
off.

Have fun,

Avery

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

"Avery Pennarun" <apenwarr@gmail.com> writes:

> So by encoding it this way, someone with a modern mailer could...

Heh, so by that definition Gnus is not modern enough; neither is webmail
interface at gmail.

>From which has originally zero level of >
>From which has one
>>From which has two
>>>From which has three

I am reasonably sure the above will be sent with one, one, two and three
gt before "From".  Is your mailer modern enough?

Re: [PATCH] Added --export option to git-send-email.

[Avery Pennarun]

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> Heh, so by that definition Gnus is not modern enough; neither is webmail
> interface at gmail.
>
>  From which has originally zero level of >
>  >From which has one
>  >>From which has two
>  >>>From which has three
>
>  I am reasonably sure the above will be sent with one, one, two and three
>  gt before "From".  Is your mailer modern enough?

I read this message at gmail, and got zero, one, two, and three
dashes, respectively.  For the sake of interest, I then connected to
gmail using IMAP from mutt, and the message was still intact.  Then I
saved it to an mbox file using mutt, and it used Content-Length
instead of From munging, so it wasn't a very good experiment :)

If you're not actually delivering your mail using mbox format (as
opposed to imap, webmail, etc), it would be quite insulting for "From
" to be munged at all, so I'm happy at least that I didn't experience
that in my tests.  On the other hand I'm surprised that gmail should
have corrupted it for you; gmail should be able to completely forget
about the concept of "From " munging since they don't use mbox
internally.  (And it's the MDA's job to munge it, not the MTA, so the
lines should never be munged while in transit *to* gmail unless the
mailer app is extremely buggy.)

Have fun,

Avery

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

"Avery Pennarun" <apenwarr@gmail.com> writes:

> And it's the MDA's job to munge it, not the MTA, so the
> lines should never be munged while in transit *to* ...

Yeah, you're right.  Sending side should not have any issues like that.

My receiving end (I think fetchmail slurps from my ISP and drops mails in
my local mbox, but it's a long time ago I configured my system...) does
quote only the "From " at the beginning, which is consistent with the
traditional mbox behaviour, so I see one, one, two, three in my local
mbox, and zero, one, two, three on gmane news article.

If this additional option claims to produce a mbox, I think:

 (1) quoting only /^From / (not /^>*From/) to be consistent with the
     standard practice is the right thing to do; and

 (2) reading side might need to also pay attention to /^>From /, in case
     somebody feeds an output from this option back to send-email.

However, strictly speaking,(2) may break the standard workflow of
generating patches with format-patch and feeding the result to send-email,
as format-patch does not do /^From / munging (and it shouldn't).  The
issue is mostly theoretical --- it only matters if your commit log has a
line that begins with ">From ", and people who have worked with e-mail for
any nontrivial period have already learned to reword their sentences to
avoid lines that begin with "From " (or ">From ", for that matter) anyway.

Re: [PATCH] Added --export option to git-send-email.

[Avery Pennarun]

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
>  If this additional option claims to produce a mbox, I think:
>
>   (1) quoting only /^From / (not /^>*From/) to be consistent with the
>      standard practice is the right thing to do; and
>
>   (2) reading side might need to also pay attention to /^>From /, in case
>      somebody feeds an output from this option back to send-email.
>
>  However, strictly speaking,(2) may break the standard workflow of
>  generating patches with format-patch and feeding the result to send-email,
>  as format-patch does not do /^From / munging (and it shouldn't).

Note that it's generally very bad practice to do (2) unless you always
quote /^>*From/.  Quoting only /^From/ and *then* trying to dequote it
correctly actually increases the number of places where you can
corrupt a message.  As a sign that very few programs do (2), I think
it's pretty clear that a lot more people see "From" rewritten as
">From" in their mail app of choice than the reverse.

There is also some debate about what "standard practice" means.  See:
http://homepages.tesco.net/J.deBoynePollard/FGA/mail-mbox-formats.html
.

If git is going to start actually producing mbox files (as opposed to
just individual messages as it does now), it should probably
explicitly take a stance on the issue... or perhaps make it
configurable.

Have fun,

Avery

Re: [PATCH] Added --export option to git-send-email.

[Eduard - Gabriel Munteanu]

On Sun, 13 Jul 2008 19:42:35 -0400
"Avery Pennarun" <apenwarr@gmail.com> wrote:

> On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> >  If this additional option claims to produce a mbox, I think:
> >
> >   (1) quoting only /^From / (not /^>*From/) to be consistent with
> > the standard practice is the right thing to do; and
> >
> >   (2) reading side might need to also pay attention to /^>From /,
> > in case somebody feeds an output from this option back to
> > send-email.
> >
> >  However, strictly speaking,(2) may break the standard workflow of
> >  generating patches with format-patch and feeding the result to
> > send-email, as format-patch does not do /^From / munging (and it
> > shouldn't).
> 
> Note that it's generally very bad practice to do (2) unless you always
> quote /^>*From/.  Quoting only /^From/ and *then* trying to dequote it
> correctly actually increases the number of places where you can
> corrupt a message.  As a sign that very few programs do (2), I think
> it's pretty clear that a lot more people see "From" rewritten as
> ">From" in their mail app of choice than the reverse.

Junio is right when he says we should match against "From " instead of
"From" (i.e. we should not touch lines beginning with "Fromage" for
example). Should I resubmit or can it be corrected during the merge?
 
> There is also some debate about what "standard practice" means.  See:
> http://homepages.tesco.net/J.deBoynePollard/FGA/mail-mbox-formats.html
> .

When I started working on this, I visited Wikipedia which provided a
link to qmail's site, which looks quite authoritative on this matter:
http://www.qmail.org/man/man5/mbox.html

I just followed that spec.

> If git is going to start actually producing mbox files (as opposed to
> just individual messages as it does now), it should probably
> explicitly take a stance on the issue... or perhaps make it
> configurable.
> 
> Have fun,
> 
> Avery

Re: [PATCH] Added --export option to git-send-email.

[Eduard - Gabriel Munteanu]

On Sun, 13 Jul 2008 15:44:29 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> However, strictly speaking,(2) may break the standard workflow of
> generating patches with format-patch and feeding the result to
> send-email, as format-patch does not do /^From / munging (and it
> shouldn't).  The issue is mostly theoretical --- it only matters if
> your commit log has a line that begins with ">From ", and people who
> have worked with e-mail for any nontrivial period have already
> learned to reword their sentences to avoid lines that begin with
> "From " (or ">From ", for that matter) anyway.

Munging happens only when doing --export. If you don't supply that
option, it won't affect anything, so there is no breakage.

BTW, git-format-patch already produces output somewhat compatible with
mbox, as it adds a From_ line.


	Eduard

Re: [PATCH] Added --export option to git-send-email.

[Junio C Hamano]

"Avery Pennarun" <apenwarr@gmail.com> writes:

> If git is going to start actually producing mbox files (as opposed to
> just individual messages as it does now), it should probably
> explicitly take a stance on the issue...

Yeah, that makes one reason I should not be enthusiastic to take this
patch.

Re: [PATCH] Added --export option to git-send-email.

[Avery Pennarun]

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
> > If git is going to start actually producing mbox files (as opposed to
>  > just individual messages as it does now), it should probably
>  > explicitly take a stance on the issue...
>
> Yeah, that makes one reason I should not be enthusiastic to take this
>  patch.

Eduard: perhaps instead of a --export option, what about an option to
run an external program that will take the given email on stdin and
process it however you want? ... aha, it seems this already exists in
the --smtp-server option.  So a shell script like this as your
--smtp-server should do what you want:

    #!/bin/sh
    exec sed s/'^\(>*From \)/>\1/'

Thus the result of git-send-email would be a series of emails
concatenated to stdout, with From lines escaped appropriately.

Have fun,

Avery