Added --export option to git-send-email.

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.

---
 Documentation/git-send-email.txt |    6 ++++++
 git-send-email.perl              |   19 +++++++++++++++++++
 2 files changed, 25 insertions(+), 0 deletions(-)

index afbb294..17a59dd 100644
@@ -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.

index 3564419..53539cf 100755
@@ -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

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

That wouldn't be a reversible operation.

Have fun,

Avery

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

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

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

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.

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

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

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?

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.

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