Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Ryan Anderson wrote: Since these emails are sent *very* fast, delivery order tends to be the dominating factor in how they sort in your inbox, as they will all have the same time. So that's a trifle annoying. That's trivially fixable: just generate your own Date: header and add a second for each email. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Be careful whilst playing under the anvil tree. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: All emails are sent as a reply to the previous email, making it easy to skip a collection of emails that are uninteresting. I understand why _some_ people consider this preferable, but wonder if this should have a knob to be tweaked. For example, I myself often find it very hard to read when a cascading thread goes very deep like this: [PATCH 0/9] cover [PATCH 1/9] first one [PATCH 2/9] second one [PATCH 3/9] third one in the series ... and prefer to see this instead (this assumes your MUA is half-way decent and lets you sort by subject): [PATCH 0/9] cover [PATCH 1/9] first one [PATCH 2/9] second one [PATCH 3/9] third one in the series ... In testing this, I think I figured out *why* the former is preferred - it guarantees the sorting when in the standard mode of order by date. Since these emails are sent *very* fast, delivery order tends to be the dominating factor in how they sort in your inbox, as they will all have the same time. So that's a trifle annoying. Yes, sorting by subject will fix it, but threaded + subject is actually something I'm not sure much of anything supports. (It's not instantly obvious how to do it in mutt, for example - though, admittedly, Mutt may very well have a way to do it.) I noticed this while testing my 2 new fixes - those will sent in a few seconds. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Junio C Hamano wrote: Also, I wonder if running lc() to downcase the local-part[*] is safe/allowed/correct mostly/no/no. It's unlikely to be a real-life problem, but we still shouldn't do it. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Amusements to virtue are like breezes of air to the flame -- gentle ones will fan it, but strong ones will put it out. -- David Thomas - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Sun, Jul 31, 2005 at 07:52:42PM -0400, Ryan Anderson wrote: On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: ... Also you seem to be losing the ordering in @to and @cc by the use of uniquefying keys %to and keys %cc. I can not offhand tell if it matters, but you probably would care, at least for the primary recipients listed in @to array. Well, it was kind of annoying to see the same email address appear 2-3 times in the email, because of the way I pull in all the relevant emails from various places. So I really needed a way to cull the duplicates. I don't believe ordering is really significant in To: or Cc: lines, for really anyone. I could do soemthing like this, instead, I suppose: my @clean_to = (); my %dupe_check_to = (); foreach my $to_entry (@to) { if (!$dupe_check_to{Email::Valid-address($to_entry)}++) { push @clean_to, $to_entry; } } my $to = join(, , @clean_to); I just like the first one a little better (though, I can't really pin down why). Or, more simply (if perl'y): my %tmp; @to = grep { ! $tmp{Email::Valid-address($_)}++ } @to; ...although I'd probably defensively localize the temporary var: { my %tmp; @to = grep { ! $tmp{Email::Valid-address($_)}++ } @to; } -- Short-term expediency always fails in the long term. -- The Preacher at Arrakeen +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Noel Maddy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Mon, Aug 01, 2005 at 06:08:00PM -0400, Noel Maddy wrote: On Sun, Jul 31, 2005 at 07:52:42PM -0400, Ryan Anderson wrote: On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: ... Also you seem to be losing the ordering in @to and @cc by the use of uniquefying keys %to and keys %cc. I can not offhand tell if it matters, but you probably would care, at least for the primary recipients listed in @to array. Well, it was kind of annoying to see the same email address appear 2-3 times in the email, because of the way I pull in all the relevant emails from various places. So I really needed a way to cull the duplicates. I don't believe ordering is really significant in To: or Cc: lines, for really anyone. I could do soemthing like this, instead, I suppose: my @clean_to = (); my %dupe_check_to = (); foreach my $to_entry (@to) { if (!$dupe_check_to{Email::Valid-address($to_entry)}++) { push @clean_to, $to_entry; } } my $to = join(, , @clean_to); I just like the first one a little better (though, I can't really pin down why). Or, more simply (if perl'y): my %tmp; @to = grep { ! $tmp{Email::Valid-address($_)}++ } @to; ...although I'd probably defensively localize the temporary var: { my %tmp; @to = grep { ! $tmp{Email::Valid-address($_)}++ } @to; } Duh. ENOCAFFEINE. my %tmp; @to = grep { ! $tmp-{$_}++ Email::Valid-address($_) } @to; -- Short-term expediency always fails in the long term. -- The Preacher at Arrakeen +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Noel Maddy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- The more people you rule over, the less an individual matters. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Noel Maddy [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
This is based off of GregKH's script, send-lots-of-email.pl, and strives to do all the nice things a good subsystem maintainer does when forwarding a patch or 50 upstream: All the prior handlers of the patch, as determined by the Signed-off-by: lines, and/or the author of the commit, are cc:ed on the email. All emails are sent as a reply to the previous email, making it easy to skip a collection of emails that are uninteresting. Signed-off-by: Ryan Anderson [EMAIL PROTECTED] --- Makefile |2 git-send-email-script | 265 + 2 files changed, 266 insertions(+), 1 deletions(-) create mode 100755 git-send-email-script 55d4b5b7a11448d60eb00b5a7081954663842b06 diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -62,7 +62,7 @@ SCRIPTS=git git-apply-patch-script git-m git-format-patch-script git-sh-setup-script git-push-script \ git-branch-script git-parse-remote git-verify-tag-script \ git-ls-remote-script git-clone-dumb-http git-rename-script \ - git-request-pull-script + git-request-pull-script git-send-email-script PROG= git-update-cache git-diff-files git-init-db git-write-tree \ git-read-tree git-commit-tree git-cat-file git-fsck-cache \ diff --git a/git-send-email-script b/git-send-email-script new file mode 100755 --- /dev/null +++ b/git-send-email-script @@ -0,0 +1,265 @@ +#!/usr/bin/perl -w +# horrible hack of a script to send off a large number of email messages, one after +# each other, all chained together. This is useful for large numbers of patches. +# +# Use at your own risk +# +# greg kroah-hartman Jan 8, 2002 +# [EMAIL PROTECTED] +# +# GPL v2 (See COPYING) +# +# Ported to support git mbox format files by Ryan Anderson [EMAIL PROTECTED] +# +# Sends emails to the email listed on the command line. +# +# updated to give a valid subject and CC the owner of the patch - Jan 2005 +# first line of the message is who to CC, +# and second line is the subject of the message. +# + +use strict; +use warnings; +use Term::ReadLine; +use Mail::Sendmail; +use Getopt::Long; +use Data::Dumper; +use Email::Valid; + +# Variables we fill in automatically, or via prompting: +my (@to,@cc,$initial_reply_to,$initial_subject,@files,$from); + +# Example of them +# modify these options each time you run the script +#$to = '[EMAIL PROTECTED],git@vger.kernel.org'; +#$initial_reply_to = ''; #[EMAIL PROTECTED]'; +#$initial_subject = [PATCH] Deb package build fixes; [EMAIL PROTECTED] = (qw( +#0001-Make-debian-rules-executable-and-correct-the-spelling-of-rsync-in.txt +#0002-Debian-packages-should-include-the-binaries.txt +#0003-The-deb-package-building-needs-these-two-new-files-to-work-correctly.txt +#)); + +# change this to your email address. +#$from = Ryan Anderson [EMAIL PROTECTED]; + +my $term = new Term::ReadLine 'git-send-email'; + +# Begin by accumulating all the variables (defined above), that we will end up +# needing, first, from the command line: + +my $rc = GetOptions(from=s = \$from, +in-reply-to=s = \$initial_reply_to, + subject=s = \$initial_subject, + to=s = [EMAIL PROTECTED], +); + +# Now, let's fill any that aren't set in with defaults: + +open(GITVAR,-|,git-var,-l) + or die Failed to open pipe from git-var: $!; + +my ($author,$committer); +while(GITVAR) { + chomp; + my ($var,$data) = split /=/,$_,2; + my @fields = split /\s+/, $data; + + my $ident = join( , @fields[0...(@fields-3)]); + + if ($var eq 'GIT_AUTHOR_IDENT') { + $author = $ident; + } elsif ($var eq 'GIT_COMMITTER_IDENT') { + $committer = $ident; + } +} +close(GITVAR); + + +if (!defined $from) { + $from = $author || $committer; + 1 while (!defined ($_ = $term-readline(Who should the emails appear to be from? , + $from))); + $from = $_; + print Emails will be sent from: , $from, \n; +} + +if ([EMAIL PROTECTED]) { + 1 while (!defined ($_ = $term-readline(Who should the emails be sent to? , + ))); + my $to = $_; + push @to, split /,/, $to; +} + +if (!defined $initial_subject) { + 1 while (!defined ($_ = + $term-readline(What subject should the emails start with? , + $initial_subject))); + $initial_subject = $_; +} + +if (!defined $initial_reply_to) { + 1 while (!defined ($_ = + $term-readline(Message-ID to be used as In-Reply-To? , + $initial_reply_to))); + $initial_reply_to = $_; +} + +# Now that all the defaults are set, process the rest of the command line +# arguments and collect up the files that need to be processed. +for my $f (@ARGV) { + if (-d $f) { + opendir(DH,$f) + or die Failed
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Hi, Ryan Anderson wrote: And yes, I did generate this thread with this script - so I have proof that it works nicely. It might make sense to create a Patch 0/N with a short explanation, and have the actual patches be replies to that -- or to patch 1/N if that's not necessary. As it is, patch N hangs off patch N-1 in my email threading view, which gets slightly cumbersome if N10. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED] Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Nothing makes a person more productive than the last minute. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
Oh, another thing. Could you refrain from doing quoted-printable when possible? Thanks. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add git-send-email-script - tool to send emails from git-format-patch-script
On Sun, Jul 31, 2005 at 02:45:29AM -0700, Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: All emails are sent as a reply to the previous email, making it easy to skip a collection of emails that are uninteresting. I understand why _some_ people consider this preferable, but wonder if this should have a knob to be tweaked. Hmm, fair enough. I'll send a few more patches in a minute that deal with the things in this email but for now: --chain-reply-to (or --no-chain-reply-to) Will toggle between these two behaviors. (This will not be prompted for by the ReadLine interface, btw.) +# horrible hack of a script to send off a large number of email messages, one after +# each other, all chained together. This is useful for large numbers of patches. +# +# Use at your own risk Well, if it is Use at your own risk maybe it should stay outside the official distribution for a while until it gets safer ;-). Heh. I missed some comments that I meant to clean up that were in Greg's original script. One of the patches will clean up the comments. + my @fields = split /\s+/, $data; + my $ident = join( , @fields[0...(@fields-3)]); Wouldn't s/.*// be easier than splitting and joining? Most of GIT_COMMITTER_IDENT (and GIT_AUTHOR_IDENT) is use controllable, except for the date section of it. I know we delimit that with spaces, so the above is guaranteed to work unless we change the format that git-var returns. If I hope that nobody has done something like: GIT_AUTHOR=Ryan Anderson GIT_AUTHOR_EMAIL=[EMAIL PROTECTED] I get more confusing results. (I suddenly have to think about what that regular expression does in this case - and I'm pretty sure that the one you gave would do bad things.) Probably the best fix for this would be to take libgit.a, make a shared library out of it, and then interface the Perl scripts directly with it via a .xs module. I was thinking that I'd rather have direct access to the git_ident* functions than calling out to git-var, anyway. Consider that a plan for a revamp after the core seems to have settled down a bit more. +if (!defined $from) { + $from = $author || $committer; + 1 while (!defined ($_ = $term-readline(Who should the emails appear to be from? , + $from))); Judging from your past patches, you seem to really like statement modifiers[*]. While they _are_ valid Perl constructs, it is extremely hard to read when used outside very simple idiomatic use. Please consider rewriting the above and the like using compound statements[*] (I am using these terms according to the definition in perlsyn.pod). Remember, there are people Perl is not their native language, but are intelligent enough to be of great help fixing problems in programs you write in Perl. To most of them, compound statements are more familiar, so try to be gentle to them. I copied this from another program of mine, and I'm *sure* I copied the style directly from a ReadLine example. But, I can't find a current example that says this is good, so, I'll fix this, too. It is rather ugly. (The other uses of this style are... less bad, IMO, than this abuse here.) + opendir(DH,$f) + or die Failed to opendir $f: $!; + push @files, map { +$f . / . $_ } grep !/^\.{1,2}$/, + sort readdir(DH); Maybe skip potential subdirs while you are at it, something like this? push @files, sort grep { -f $_ } map { $f/$_ } readdir(DH) Good point. One one hand I'd say, Let it break for people who do strange things like that, but I'll make it safer anyway. (Someone is going to reply and ask for it to recurse into subdirectories now. Maybe Andrew Morton would find that useful with his rather massive collection of patches in -mm kernels. But that's a feature for next week.) + my $pseudo_rand = int (rand(4200)); + $message_id = [EMAIL PROTECTED]; + print new message id = $message_id\n; I doubt this hardcoded foobar.com is a good idea. Did you mean to print it, by the way? I'll convert this to something that is based off the $from address instead. It's probably better that way, anyway. + $to{lc(Email::Valid-address($_))}++ for (@to); + my $to = join(,, keys %to); Is this the culprit that produced this mechanical-looking line? To: [EMAIL PROTECTED],git@vger.kernel.org No, that line was exactly what I put into the readline entry. Interestingly enough, you do not seem to do it for the From: line. From: Ryan Anderson [EMAIL PROTECTED] Also you seem to be losing the ordering in @to and @cc by the use of uniquefying keys %to and keys %cc. I can not offhand tell if it matters, but you probably would care, at least for the primary recipients listed in @to array. Well, it was kind of annoying to see the same email address appear 2-3 times in the email,