threads / patch / 14393

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

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

## tl;dr

15 messages between Jul 10, 2008 and Jul 14, 2008. Diffs are folded; open one to read it.

replies: 14people: 3as markdown or json

Eduard - Gabriel Munteanu· Jul 10, 2008, 14:07 UTC · lore

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(-)
Show changes to 2 files +25 −0

Documentation/git-send-email.txt, git-send-email.perl

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
Junio C Hamano· Jul 11, 2008, 07:03 UTC · re: Eduard - Gabriel Munteanu · lore

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

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?"
Eduard - Gabriel Munteanu· Jul 11, 2008, 19:53 UTC · re: Junio C Hamano · lore

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

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

Show 7 quoted lines
> 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
Junio C Hamano· Jul 13, 2008, 20:17 UTC · re: Eduard - Gabriel Munteanu · lore

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

Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
Show 12 quoted lines
> 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;
Avery Pennarun· Jul 13, 2008, 21:32 UTC · re: Junio C Hamano · lore

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

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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
Junio C Hamano· Jul 13, 2008, 21:36 UTC · re: Avery Pennarun · lore

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

"Avery Pennarun" <apenwarr@gmail.com> writes:
Show 13 quoted lines
> 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.

Avery Pennarun· Jul 13, 2008, 21:44 UTC · re: Junio C Hamano · lore

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

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
>  >> 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
Junio C Hamano· Jul 13, 2008, 22:05 UTC · re: Avery Pennarun · lore

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

"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?

Avery Pennarun· Jul 13, 2008, 22:21 UTC · re: Junio C Hamano · lore

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

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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
Junio C Hamano· Jul 13, 2008, 22:44 UTC · re: Avery Pennarun · lore

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

"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.

Avery Pennarun· Jul 13, 2008, 23:42 UTC · re: Junio C Hamano · lore

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

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 11 quoted lines
>  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
Eduard - Gabriel Munteanu· Jul 13, 2008, 23:58 UTC · re: Avery Pennarun · lore

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

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

Show 21 quoted lines
> 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.
Show 8 quoted lines
> 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 C Hamano· Jul 14, 2008, 03:13 UTC · re: Avery Pennarun · lore

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

"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.

Avery Pennarun· Jul 14, 2008, 03:41 UTC · re: Junio C Hamano · lore

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

On 7/13/08, Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> "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
Eduard - Gabriel Munteanu· Jul 14, 2008, 00:05 UTC · re: Junio C Hamano · lore

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

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

Show 8 quoted lines
> 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

← back to recent threads