* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: Andreas Ericsson @ 2009-04-07 22:10 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Witten, demerphq, git
In-Reply-To: <20090407220048.GB18144@coredump.intra.peff.net>
Jeff King wrote:
> On Tue, Apr 07, 2009 at 04:42:36PM -0500, Michael Witten wrote:
>
>> I'll have to give that a try. However, I've been entertaining the idea
>> of rewriting the whole thing anyway; it's in need of much more than
>> reformatting.
>
> Just my two cents, but if you are considering re-writing send-email, I
> would suggest two things:
>
> 1. Make much heavier use of existing CPAN libraries. A lot of the ugly
> code is trying to handle corner cases in rfc2822 and mime parsing
> and generation. And I would not be surprised if there were still
> bugs in that ugly code.
>
> 2. Make a new command to compete with send-email instead of using the
> same name. This means that people who are really put off by
> CPAN dependencies from (1) above won't be negatively impacted. And
> you can drop any historical interface warts if you want to.
>
3. Make it capable of sending email directly from commits rather than
than having to generate them as files first. For bonus-points, use
git sequencer or some other "git rebase -i"-esque mangling thing
first, with capabilities of adding a cover-letter for patch-series.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* [PATCH RFC 1/6] Re: send-email: Add --delay for separating emails
From: Nicolas Sebrecht @ 2009-04-07 22:08 UTC (permalink / raw)
To: Jeff King; +Cc: Michael Witten, git
In-Reply-To: <20090407215143.GA18144@coredump.intra.peff.net>
On Tue, Apr 07, 2009 at 05:51:43PM -0400, Jeff King wrote:
> > When sending a patch series, the emails often arrive at the final
> > destination out of order; though these emails should be chained
> > via the In-Reply-To headers, some mail-viewing systems display
> > by order of arrival instead.
> >
> > The --delay option provides a means for specifying that there
> > should be a certain number of seconds of delay between sending
> > emails, so that the arrival order can be controlled better.
> >
> > Signed-off-by: Michael Witten <mfwitten@gmail.com>
> I think it may still be reasonable to implement a solution that only
> covers some of the cases, but I what I am asking is if we know what
> percentage of the cases that is. If we are preventing only 1% of
> out-of-order deliveries with this, I question whether it is worth the
> bother.
IMHO, this improvement is broken by design. We try to fix a
receiver-only issue by a sender side fix.
If the receiver wants the patch series be in a good ordered _for sure_, he
has to switch to a client mail supporting the In-Reply-To chains.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: Jeff King @ 2009-04-07 22:00 UTC (permalink / raw)
To: Michael Witten; +Cc: demerphq, git
In-Reply-To: <b4087cc50904071442ka298564x52112c1eac9ac284@mail.gmail.com>
On Tue, Apr 07, 2009 at 04:42:36PM -0500, Michael Witten wrote:
> I'll have to give that a try. However, I've been entertaining the idea
> of rewriting the whole thing anyway; it's in need of much more than
> reformatting.
Just my two cents, but if you are considering re-writing send-email, I
would suggest two things:
1. Make much heavier use of existing CPAN libraries. A lot of the ugly
code is trying to handle corner cases in rfc2822 and mime parsing
and generation. And I would not be surprised if there were still
bugs in that ugly code.
2. Make a new command to compete with send-email instead of using the
same name. This means that people who are really put off by
CPAN dependencies from (1) above won't be negatively impacted. And
you can drop any historical interface warts if you want to.
-Peff
^ permalink raw reply
* Re: Showing the version of a file that's in the Index.
From: Markus Heidelberg @ 2009-04-07 21:57 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <874ox0w7ak.fsf@iki.fi>
Teemu Likonen, 07.04.2009:
> Or
>
> git show :file
Huh, I use git-show daily for commits, but I completely forgot about it
for files when replying. I already felt strange about having to pass an
option.
^ permalink raw reply
* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: demerphq @ 2009-04-07 21:57 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <9b18b3110904071444g2a8c4b66l9c22bd5ffabe3d6a@mail.gmail.com>
2009/4/7 demerphq <demerphq@gmail.com>:
> 2009/4/7 Michael Witten <mfwitten@gmail.com>:
>> On Tue, Apr 7, 2009 at 16:35, demerphq <demerphq@gmail.com> wrote:
>>> 2009/4/7 Michael Witten <mfwitten@gmail.com>:
>>>> +## WARNING! ACHTUNG! ATTENTION! ADVERTENCIA!
>>>> +## Currently, this file uses tabs (like the rest of git source) to
>>>> +## delineate code structure. Do NOT under any circumstances mix tabs
>>>> +## and spaces across lines that share a relationship in terms of layout.
>>>> +## In fact, it would currently be best to use only tabs, so please set
>>>> +## your editor(s) accordingly. This code is already trashy enough. Please
>>>> +## don't make it worse.
>>>
>>> Perltidy the file?
>>>
>>> Yves
>>
>> Oooh, that's sexy!
>>
>> I'll have to give that a try. However, I've been entertaining the idea
>> of rewriting the whole thing anyway; it's in need of much more than
>> reformatting.
>
> Yes. I notice evilness in there. Not necessarily dire burn your house
> down evilness, but evilness none the less.
BTW, I'd be glad to help out if you want, as I suspect would some of
the p5p folks.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [PATCH RFC 1/6] send-email: Add --delay for separating emails
From: Jeff King @ 2009-04-07 21:51 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1239139522-24118-1-git-send-email-mfwitten@gmail.com>
On Tue, Apr 07, 2009 at 04:25:17PM -0500, Michael Witten wrote:
> When sending a patch series, the emails often arrive at the final
> destination out of order; though these emails should be chained
> via the In-Reply-To headers, some mail-viewing systems display
> by order of arrival instead.
>
> The --delay option provides a means for specifying that there
> should be a certain number of seconds of delay between sending
> emails, so that the arrival order can be controlled better.
>
> Signed-off-by: Michael Witten <mfwitten@gmail.com>
I'm a little dubious how well this works in practice. Have you done any
experiments?
The reason I am dubious is that you are presumably delaying only a few
seconds (since anything more would be quite annoying to the user). This
may deal with a short race condition in your local mail server. But what
is the real cause of out-of-order delivery? Is it the local mail server
seeing two messages essentially "simultaneously" and then reordering
them randomly? Or is it other random delays that happen _after_ that,
like network congestion, DNS lookups, down or congested servers, time it
takes to deliver the actual message body (e.g., if your mail server
sends two simultaneously, but the first one is much larger and takes
longer to complete), etc.
Those delays can be much larger than a few seconds, and this won't help
at all there.
I think it may still be reasonable to implement a solution that only
covers some of the cases, but I what I am asking is if we know what
percentage of the cases that is. If we are preventing only 1% of
out-of-order deliveries with this, I question whether it is worth the
bother.
-Peff
^ permalink raw reply
* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: demerphq @ 2009-04-07 21:44 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <b4087cc50904071442ka298564x52112c1eac9ac284@mail.gmail.com>
2009/4/7 Michael Witten <mfwitten@gmail.com>:
> On Tue, Apr 7, 2009 at 16:35, demerphq <demerphq@gmail.com> wrote:
>> 2009/4/7 Michael Witten <mfwitten@gmail.com>:
>>> +## WARNING! ACHTUNG! ATTENTION! ADVERTENCIA!
>>> +## Currently, this file uses tabs (like the rest of git source) to
>>> +## delineate code structure. Do NOT under any circumstances mix tabs
>>> +## and spaces across lines that share a relationship in terms of layout.
>>> +## In fact, it would currently be best to use only tabs, so please set
>>> +## your editor(s) accordingly. This code is already trashy enough. Please
>>> +## don't make it worse.
>>
>> Perltidy the file?
>>
>> Yves
>
> Oooh, that's sexy!
>
> I'll have to give that a try. However, I've been entertaining the idea
> of rewriting the whole thing anyway; it's in need of much more than
> reformatting.
Yes. I notice evilness in there. Not necessarily dire burn your house
down evilness, but evilness none the less.
> As a side note, Yves, I sent the patches to perl5-porters again about
> 1.6666666 hours ago, but nothing seems to have come through; I'll try
> again later.
You mean the 14 patches I just applied and pushed to blead?
:-)
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: Michael Witten @ 2009-04-07 21:42 UTC (permalink / raw)
To: demerphq; +Cc: git
In-Reply-To: <9b18b3110904071435p320e5d1dh16061d04a3a8ab57@mail.gmail.com>
On Tue, Apr 7, 2009 at 16:35, demerphq <demerphq@gmail.com> wrote:
> 2009/4/7 Michael Witten <mfwitten@gmail.com>:
>> +## WARNING! ACHTUNG! ATTENTION! ADVERTENCIA!
>> +## Currently, this file uses tabs (like the rest of git source) to
>> +## delineate code structure. Do NOT under any circumstances mix tabs
>> +## and spaces across lines that share a relationship in terms of layout.
>> +## In fact, it would currently be best to use only tabs, so please set
>> +## your editor(s) accordingly. This code is already trashy enough. Please
>> +## don't make it worse.
>
> Perltidy the file?
>
> Yves
Oooh, that's sexy!
I'll have to give that a try. However, I've been entertaining the idea
of rewriting the whole thing anyway; it's in need of much more than
reformatting.
As a side note, Yves, I sent the patches to perl5-porters again about
1.6666666 hours ago, but nothing seems to have come through; I'll try
again later.
Michael
^ permalink raw reply
* Re: [PATCH] for-each-ref: remove multiple xstrdup() in get_short_ref()
From: Jeff King @ 2009-04-07 21:41 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <20090407074435.GB7327@coredump.intra.peff.net>
On Tue, Apr 07, 2009 at 03:44:35AM -0400, Jeff King wrote:
> + if (1 != sscanf(ref, scanf_fmts[i], short_name))
> [...]
> + if (j == i) {
> + ref += strlen(ref) - strlen(short_name);
> + break;
> + }
Actually, I am not sure this is correct, either. It is making the
assumption that the short_name is always a suffix of the ref. But one of
the rev_parse_rules is:
"refs/remotes/%.*s/HEAD"
for which this is not true. _But_ as it happens, this rule doesn't
actually work in reverse because of the way scanf works with %s. The
code:
sscanf("refs/remotes/origin/HEAD", "refs/remotes/%s/HEAD", buf);
will put "origin/HEAD" in buf, not "origin"; %s eats until it sees
whitespace (which should not be occuring in a ref, fortunately).
So it actually _is_ correct to assume with the current code that the
short_name is always a suffix, but I am not sure if that is what we
actually want. We will always see "$remote/HEAD" instead of "$remote".
Part of me actually thinks the "incorrect" behavior we are doing now is
actually more explicit and readable. But if that is the case, we should
perhaps simply be excluding that final rule explicitly, and then our
"suffix" assumption will hold.
-Peff
^ permalink raw reply
* Re: [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: demerphq @ 2009-04-07 21:35 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1239139522-24118-6-git-send-email-mfwitten@gmail.com>
2009/4/7 Michael Witten <mfwitten@gmail.com>:
> +## WARNING! ACHTUNG! ATTENTION! ADVERTENCIA!
> +## Currently, this file uses tabs (like the rest of git source) to
> +## delineate code structure. Do NOT under any circumstances mix tabs
> +## and spaces across lines that share a relationship in terms of layout.
> +## In fact, it would currently be best to use only tabs, so please set
> +## your editor(s) accordingly. This code is already trashy enough. Please
> +## don't make it worse.
Perltidy the file?
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH RFC 6/6] send-email: Remove horrible mix of tabs and spaces
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1239139522-24118-5-git-send-email-mfwitten@gmail.com>
For the most part, I ran a search for all the lines
that match:
^[\t]*[ ]+
and then I manually replaced the offending text with
an appropriate number of tabs.
While scanning through the file, I also tried to format
some of the code so as to obviate future mixing; I also
fixed one horrendously egregious section of code, where
someone was trying to be unnecessarily compact.
Currently, no lines match the following:
[\t]+[ ]+
[ ]+[\t]+
So, it should be reasonably clean.
The whole file is still horrendous.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-send-email.perl | 282 +++++++++++++++++++++++++++++++--------------------
1 files changed, 170 insertions(+), 112 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index c3e3598..a4c24f3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -16,6 +16,14 @@
# and second line is the subject of the message.
#
+## WARNING! ACHTUNG! ATTENTION! ADVERTENCIA!
+## Currently, this file uses tabs (like the rest of git source) to
+## delineate code structure. Do NOT under any circumstances mix tabs
+## and spaces across lines that share a relationship in terms of layout.
+## In fact, it would currently be best to use only tabs, so please set
+## your editor(s) accordingly. This code is already trashy enough. Please
+## don't make it worse.
+
use strict;
use warnings;
use Term::ReadLine;
@@ -118,19 +126,20 @@ sub format_2822_time {
die ("local time offset greater than or equal to 24 hours\n");
}
- return sprintf("%s, %2d %s %d %02d:%02d:%02d %s%02d%02d",
- qw(Sun Mon Tue Wed Thu Fri Sat)[$localtm[6]],
- $localtm[3],
- qw(Jan Feb Mar Apr May Jun
- Jul Aug Sep Oct Nov Dec)[$localtm[4]],
- $localtm[5]+1900,
- $localtm[2],
- $localtm[1],
- $localtm[0],
- ($offset >= 0) ? '+' : '-',
- abs($offhour),
- $offmin,
- );
+ return sprintf(
+ "%s, %2d %s %d %02d:%02d:%02d %s%02d%02d",
+ qw(Sun Mon Tue Wed Thu Fri Sat)[$localtm[6]],
+ $localtm[3],
+ qw(Jan Feb Mar Apr May Jun
+ Jul Aug Sep Oct Nov Dec)[$localtm[4]],
+ $localtm[5]+1900,
+ $localtm[2],
+ $localtm[1],
+ $localtm[0],
+ ($offset >= 0) ? '+' : '-',
+ abs($offhour),
+ $offmin,
+ );
}
my $have_email_valid = eval { require Email::Valid; 1 };
@@ -194,30 +203,30 @@ my ($validate, $confirm);
my (@suppress_cc);
my %config_bool_settings = (
- "thread" => [\$thread, 1],
- "chainreplyto" => [\$chain_reply_to, 1],
- "suppressfrom" => [\$suppress_from, undef],
- "signedoffbycc" => [\$signed_off_by_cc, undef],
- "signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
- "validate" => [\$validate, 1],
+ "thread" => [\$thread, 1],
+ "chainreplyto" => [\$chain_reply_to, 1],
+ "suppressfrom" => [\$suppress_from, undef],
+ "signedoffbycc" => [\$signed_off_by_cc, undef],
+ "signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
+ "validate" => [\$validate, 1],
);
my %config_settings = (
- "delay" => \$delay,
- "smtpserver" => \$smtp_server,
- "smtpserverport" => \$smtp_server_port,
- "smtpuser" => \$smtp_authuser,
- "smtppass" => \$smtp_authpass,
- "to" => \@to,
- "cc" => \@initial_cc,
- "cccmd" => \$cc_cmd,
- "aliasfiletype" => \$aliasfiletype,
- "bcc" => \@bcclist,
- "aliasesfile" => \@alias_files,
- "suppresscc" => \@suppress_cc,
- "envelopesender" => \$envelope_sender,
- "multiedit" => \$multiedit,
- "confirm" => \$confirm,
+ "delay" => \$delay,
+ "smtpserver" => \$smtp_server,
+ "smtpserverport" => \$smtp_server_port,
+ "smtpuser" => \$smtp_authuser,
+ "smtppass" => \$smtp_authpass,
+ "to" => \@to,
+ "cc" => \@initial_cc,
+ "cccmd" => \$cc_cmd,
+ "aliasfiletype" => \$aliasfiletype,
+ "bcc" => \@bcclist,
+ "aliasesfile" => \@alias_files,
+ "suppresscc" => \@suppress_cc,
+ "envelopesender" => \$envelope_sender,
+ "multiedit" => \$multiedit,
+ "confirm" => \$confirm,
);
# Handle Uncouth Termination
@@ -247,38 +256,39 @@ $SIG{INT} = \&signal_handler;
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
-my $rc = GetOptions("sender|from=s" => \$sender,
- "in-reply-to=s" => \$initial_reply_to,
- "subject=s" => \$initial_subject,
- "to=s" => \@to,
- "cc=s" => \@initial_cc,
- "bcc=s" => \@bcclist,
- "chain-reply-to!" => \$chain_reply_to,
- "delay=i" => \$delay,
- "smtp-server=s" => \$smtp_server,
- "smtp-server-port=i" => \$smtp_server_port,
- "smtp-user=s" => \$smtp_authuser,
- "smtp-pass:s" => \$smtp_authpass,
- "smtp-ssl" => sub { $smtp_encryption = 'ssl' },
- "smtp-encryption=s" => \$smtp_encryption,
- "identity=s" => \$identity,
- "annotate" => \$annotate,
- "compose:s" => \$compose,
- "quiet" => \$quiet,
- "cc-cmd=s" => \$cc_cmd,
- "suppress-from!" => \$suppress_from,
- "suppress-cc=s" => \@suppress_cc,
- "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
- "confirm=s" => \$confirm,
- "dry-run" => \$dry_run,
- "envelope-sender=s" => \$envelope_sender,
- "thread!" => \$thread,
- "validate!" => \$validate,
- "format-patch!" => \$format_patch,
- );
+my $rc = GetOptions(
+ "sender|from=s" => \$sender,
+ "in-reply-to=s" => \$initial_reply_to,
+ "subject=s" => \$initial_subject,
+ "to=s" => \@to,
+ "cc=s" => \@initial_cc,
+ "bcc=s" => \@bcclist,
+ "chain-reply-to!" => \$chain_reply_to,
+ "delay=i" => \$delay,
+ "smtp-server=s" => \$smtp_server,
+ "smtp-server-port=i" => \$smtp_server_port,
+ "smtp-user=s" => \$smtp_authuser,
+ "smtp-pass:s" => \$smtp_authpass,
+ "smtp-ssl" => sub { $smtp_encryption = 'ssl' },
+ "smtp-encryption=s" => \$smtp_encryption,
+ "identity=s" => \$identity,
+ "annotate" => \$annotate,
+ "compose:s" => \$compose,
+ "quiet" => \$quiet,
+ "cc-cmd=s" => \$cc_cmd,
+ "suppress-from!" => \$suppress_from,
+ "suppress-cc=s" => \@suppress_cc,
+ "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
+ "confirm=s" => \$confirm,
+ "dry-run" => \$dry_run,
+ "envelope-sender=s" => \$envelope_sender,
+ "thread!" => \$thread,
+ "validate!" => \$validate,
+ "format-patch!" => \$format_patch,
+);
unless ($rc) {
- usage();
+ usage();
}
die "Cannot run git format-patch from outside a repository\n"
@@ -407,29 +417,55 @@ sub split_addrs {
my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
- mutt => sub { my $fh = shift; while (<$fh>) {
- if (/^\s*alias\s+(\S+)\s+(.*)$/) {
- my ($alias, $addr) = ($1, $2);
- $addr =~ s/#.*$//; # mutt allows # comments
- # commas delimit multiple addresses
- $aliases{$alias} = [ split_addrs($addr) ];
- }}},
- mailrc => sub { my $fh = shift; while (<$fh>) {
- if (/^alias\s+(\S+)\s+(.*)$/) {
- # spaces delimit multiple addresses
- $aliases{$1} = [ split(/\s+/, $2) ];
- }}},
- pine => sub { my $fh = shift; my $f='\t[^\t]*';
- for (my $x = ''; defined($x); $x = $_) {
+ mutt => sub {
+
+ my $fh = shift;
+
+ while (<$fh>) {
+ if (/^\s*alias\s+(\S+)\s+(.*)$/) {
+ my ($alias, $addr) = ($1, $2);
+ $addr =~ s/#.*$//; # mutt allows # comments
+ # commas delimit multiple addresses
+ $aliases{$alias} = [ split_addrs($addr) ];
+ }
+ }
+ },
+
+ mailrc => sub {
+
+ my $fh = shift;
+
+ while (<$fh>) {
+ if (/^alias\s+(\S+)\s+(.*)$/) {
+ # spaces delimit multiple addresses
+ $aliases{$1} = [ split(/\s+/, $2) ];
+ }
+ }
+ },
+
+ pine => sub {
+
+ my $fh = shift;
+ my $f='\t[^\t]*';
+
+ for (my $x = ''; defined($x); $x = $_) {
chomp $x;
- $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
+ $x .= $1 while(defined($_ = <$fh>) && /^ +(.*)$/);
$x =~ /^(\S+)$f\t\(?([^\t]+?)\)?(:?$f){0,2}$/ or next;
$aliases{$1} = [ split_addrs($2) ];
- }},
- gnus => sub { my $fh = shift; while (<$fh>) {
- if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
- $aliases{$1} = [ $2 ];
- }}}
+ }
+ },
+
+ gnus => sub {
+
+ my $fh = shift;
+
+ while (<$fh>) {
+ if (/\(define-mail-alias\s+"(\S+?)"\s+"(\S+?)"\)/) {
+ $aliases{$1} = [ $2 ];
+ }
+ }
+ }
);
if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
@@ -597,10 +633,11 @@ EOT
} elsif (/^\n$/) {
$in_body = 1;
if ($need_8bit_cte) {
- print $compose_final_file "MIME-Version: 1.0\n",
- "Content-Type: text/plain; ",
- "charset=utf-8\n",
- "Content-Transfer-Encoding: 8bit\n";
+ print $compose_final_file
+ "MIME-Version: 1.0\n",
+ "Content-Type: text/plain; ",
+ "charset=utf-8\n",
+ "Content-Transfer-Encoding: 8bit\n";
}
} elsif (/^MIME-Version:/i) {
$need_8bit_cte = 0;
@@ -609,8 +646,8 @@ EOT
my $subject = $initial_subject;
$_ = "Subject: " .
($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject) :
- $subject) .
+ quote_rfc2047($subject) :
+ $subject) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
@@ -639,8 +676,10 @@ sub ask {
my $resp;
my $i = 0;
return defined $default ? $default : undef
- unless defined $term->IN and defined fileno($term->IN) and
- defined $term->OUT and defined fileno($term->OUT);
+ unless defined $term->IN
+ and defined fileno($term->IN)
+ and defined $term->OUT
+ and defined fileno($term->OUT);
while ($i++ < 10) {
$resp = $term->readline($prompt);
if (!defined $resp) { # EOF
@@ -660,8 +699,12 @@ sub ask {
my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
- $sender = ask("Who should the emails appear to be from? [$sender] ",
- default => $sender);
+
+ $sender = ask(
+ "Who should the emails appear to be from? [$sender] ",
+ default => $sender
+ );
+
print "Emails will be sent from: ", $sender, "\n";
$prompting++;
}
@@ -689,7 +732,8 @@ sub expand_aliases {
if ($thread && !defined $initial_reply_to && $prompting) {
$initial_reply_to = ask(
- "Message-ID to be used as In-Reply-To for the first email? ");
+ "Message-ID to be used as In-Reply-To for the first email? "
+ );
}
if (defined $initial_reply_to) {
$initial_reply_to =~ s/^\s*<?//;
@@ -823,18 +867,22 @@ sub sanitize_address
sub send_message
{
my @recipients = unique_email_list(@to);
- @cc = (grep { my $cc = extract_valid_address($_);
- not grep { $cc eq $_ } @recipients
- }
- map { sanitize_address($_) }
- @cc);
+
+ @cc = (grep
+ {
+ my $cc = extract_valid_address($_);
+ not grep { $cc eq $_ } @recipients
+ }
+ map { sanitize_address($_) } @cc
+ );
+
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
@recipients = (map { extract_valid_address($_) } @recipients);
my $date = format_2822_time($time++);
my $gitversion = '@@GIT_VERSION@@';
if ($gitversion =~ m/..GIT_VERSION../) {
- $gitversion = Git::version();
+ $gitversion = Git::version();
}
my $cc = join(", ", unique_email_list(@cc));
@@ -883,9 +931,13 @@ X-Mailer: git-send-email $gitversion
print " To retain the current behavior, but squelch this message,\n";
print " run 'git config --global sendemail.confirm auto'.\n\n";
}
- $_ = ask("Send this email? ([y]es|[n]o|[q]uit|[a]ll): ",
- valid_re => qr/^(?:yes|y|no|n|quit|q|all|a)/i,
- default => $ask_default);
+
+ $_ = ask(
+ "Send this email? ([y]es|[n]o|[q]uit|[a]ll): ",
+ valid_re => qr/^(?:yes|y|no|n|quit|q|all|a)/i,
+ default => $ask_default
+ );
+
die "Send this email reply required" unless defined $_;
if (/^n/i) {
return;
@@ -920,9 +972,13 @@ X-Mailer: git-send-email $gitversion
}
else {
require Net::SMTP;
- $smtp ||= Net::SMTP->new((defined $smtp_server_port)
- ? "$smtp_server:$smtp_server_port"
- : $smtp_server);
+
+ $smtp ||= Net::SMTP->new(
+ (defined $smtp_server_port)
+ ? "$smtp_server:$smtp_server_port"
+ : $smtp_server
+ );
+
if ($smtp_encryption eq 'tls') {
require Net::SMTP::SSL;
$smtp->command('STARTTLS');
@@ -1018,7 +1074,7 @@ for (my $index = 0; $index < @files; $index++) {
chomp($header[$#header]);
s/^\s+/ /;
$header[$#header] .= $_;
- } else {
+ } else {
push(@header, $_);
}
}
@@ -1136,9 +1192,9 @@ for (my $index = 0; $index < @files; $index++) {
}
else {
push @xh,
- 'MIME-Version: 1.0',
- "Content-Type: text/plain; charset=$author_encoding",
- 'Content-Transfer-Encoding: 8bit';
+ 'MIME-Version: 1.0',
+ "Content-Type: text/plain; charset=$author_encoding",
+ 'Content-Transfer-Encoding: 8bit';
}
}
}
@@ -1146,7 +1202,9 @@ for (my $index = 0; $index < @files; $index++) {
$needs_confirm = (
$confirm eq "always" or
($confirm =~ /^(?:auto|cc)$/ && @cc) or
- ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
+ ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1)
+ );
+
$needs_confirm = "inform" if ($needs_confirm && $confirm_unconfigured && @cc);
@cc = (@initial_cc, @cc);
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* [PATCH RFC 5/6] send-email: Cleanup the usage text a bit
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1239139522-24118-4-git-send-email-mfwitten@gmail.com>
All lines should be < 80 characters.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-send-email.perl | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 481bf36..c3e3598 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -42,6 +42,9 @@ package main;
sub usage {
+
+ # All printed lines should be less than 80 characters.
+
print <<EOT;
git send-email [options] <file | directory | rev-list options >
@@ -52,7 +55,8 @@ git send-email [options] <file | directory | rev-list options >
--bcc <str> * Email Bcc:
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
- --annotate * Review each patch that will be sent in an editor.
+ --annotate * Review each patch that will be sent in
+ an editor.
--compose opt <str> * Open an editor for introduction.
Sending:
@@ -69,8 +73,10 @@ git send-email [options] <file | directory | rev-list options >
Automating:
--identity <str> * Use the sendemail.<id> options.
--cc-cmd <str> * Email Cc: via `<str> \$patch_path`
- --suppress-cc <str> * author, self, sob, cc, cccmd, body, bodycc, all.
- --[no-]signed-off-by-cc * Send to Signed-off-by: addresses. Default on.
+ --suppress-cc <str> * author, self, sob, cc, cccmd, body,
+ bodycc, all.
+ --[no-]signed-off-by-cc * Send to Signed-off-by: addresses.
+ Default on.
--[no-]suppress-from * Send to self. Default off.
--[no-]chain-reply-to * Chain In-Reply-To: fields. Default on.
--[no-]thread * Use In-Reply-To: field. Default on.
@@ -81,8 +87,8 @@ git send-email [options] <file | directory | rev-list options >
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
--[no-]validate * Perform patch sanity checks. Default on.
- --[no-]format-patch * understand any non optional arguments as
- `git format-patch` ones.
+ --[no-]format-patch * Understand any non-optional arguments as
+ `git format-patch' arguments.
EOT
exit(1);
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* [PATCH RFC 4/6] send-email: --compose takes optional argument to existing file
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1239139522-24118-3-git-send-email-mfwitten@gmail.com>
Now, a user may specify an existing (in-progress) file to use as
the introductory/summary email.
The file is opened for any additional editing as usual.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-send-email.txt | 7 ++-
git-send-email.perl | 112 ++++++++++++++++++++++----------------
2 files changed, 71 insertions(+), 48 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 4b656ca..bc9ff13 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -57,8 +57,11 @@ The --cc option must be repeated for each user you want on the cc list.
or one for all of them at once.
--compose::
- Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
- introductory message for the patch series.
+ Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR, or vi to edit an
+ introductory message for the patch series. An existing file may be
+ specified as the basis for the introductory email; it will be opened
+ for editing directly. Otherwise, a new temporary file is created with
+ some default contents.
+
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
diff --git a/git-send-email.perl b/git-send-email.perl
index 098c620..481bf36 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -53,7 +53,7 @@ git send-email [options] <file | directory | rev-list options >
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--annotate * Review each patch that will be sent in an editor.
- --compose * Open an editor for introduction.
+ --compose opt <str> * Open an editor for introduction.
Sending:
--delay <int> * Delay (seconds) between sending emails.
@@ -62,7 +62,7 @@ git send-email [options] <file | directory | rev-list options >
is optional. Default 'localhost'.
--smtp-server-port <int> * Outgoing SMTP server port.
--smtp-user <str> * Username for SMTP-AUTH.
- --smtp-pass <str> * Password for SMTP-AUTH; not necessary.
+ --smtp-pass opt <str> * Password for SMTP-AUTH; not necessary.
--smtp-encryption <str> * tls or ssl; anything else disables.
--smtp-ssl * Deprecated. Use '--smtp-encryption ssl'.
@@ -159,7 +159,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
my $format_patch;
-my $compose_filename;
+my ($compose_filename, $compose_final_filename, $compose_final_is_not_empty);
# Handle interactive edition of files.
my $multiedit;
@@ -224,13 +224,12 @@ sub signal_handler {
system "stty echo";
# tmp files from --compose
- if (defined $compose_filename) {
- if (-e $compose_filename) {
- print "'$compose_filename' contains an intermediate version of the email you were composing.\n";
- }
- if (-e ($compose_filename . ".final")) {
- print "'$compose_filename.final' contains the composed email.\n"
- }
+ if (defined $compose_filename and -f $compose_filename) {
+ print "'$compose_filename' contains an intermediate version of the email you were composing.\n";
+ }
+
+ if (defined $compose_final_filename and -f $compose_final_filename) {
+ print "'$compose_final_filename' contains the composed email.\n"
}
exit;
@@ -258,7 +257,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
"annotate" => \$annotate,
- "compose" => \$compose,
+ "compose:s" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
@@ -517,21 +516,36 @@ sub get_patch_subject($) {
die "'Subject:' line expected in '$patch'";
}
-if ($compose) {
- # Note that this does not need to be secure, but we will make a small
- # effort to have it be unique
- $compose_filename = ($repo ?
- tempfile(".gitsendemail.msg.XXXXXX", DIR => $repo->repo_path()) :
- tempfile(".gitsendemail.msg.XXXXXX", DIR => "."))[1];
- open(C,">",$compose_filename)
- or die "Failed to open for writing $compose_filename: $!";
+if (defined $compose) {
+
+ my ($tmp_file, $tmp_filename) = tempfile(".gitsendemail.msg.XXXXXX", DIR => ($repo ? $repo->repo_path() : "."));
+ my $compose_file;
+ my $compose_final_file;
+
+ if ($compose ne '') {
+
+ $compose_filename = $compose;
+
+ $compose_final_filename = $tmp_filename;
+ $compose_final_file = $tmp_file
+
+ } else {
- my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
- my $tpl_subject = $initial_subject || '';
- my $tpl_reply_to = $initial_reply_to || '';
+ $compose_filename = $tmp_filename;
+ $compose_file = $tmp_file;
- print C <<EOT;
+ $compose_final_filename = "$compose_filename.final";
+ open $compose_final_file, ">", $compose_final_filename
+ or die "Failed to open '$compose_final_filename' for writing: $!";
+
+ # Help the user out with some instruction and initial headers:
+
+ my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
+ my $tpl_subject = $initial_subject || '';
+ my $tpl_reply_to = $initial_reply_to || '';
+
+ print $compose_file <<EOT;
From $tpl_sender # This line is ignored.
GIT: Lines beginning in "GIT:" will be removed.
GIT: Consider including an overall diffstat or table of contents
@@ -543,10 +557,10 @@ Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
EOT
- for my $f (@files) {
- print C "GIT: ", get_patch_subject($f), "\n";
+ for my $f (@files) {
+ print $compose_file "GIT: ", get_patch_subject($f), "\n";
+ }
}
- close(C);
my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
@@ -556,23 +570,28 @@ EOT
do_edit($compose_filename);
}
- open(C2,">",$compose_filename . ".final")
- or die "Failed to open $compose_filename.final : " . $!;
+ # Now transform the user-edited introduction into something
+ # suitable for sending via email; the user's editor may have
+ # unlinked the original file and replaced it with an entirely
+ # new one. If this be the case, then it wouldn't do just to
+ # seek to the beginning and start reading, because then only
+ # the original content would be retrieved. Consequently, the
+ # file must be reopened to be safe (note, the original
+ # filehandle is closed automatically).
- open(C,"<",$compose_filename)
- or die "Failed to open $compose_filename : " . $!;
+ open $compose_file, "<", $compose_filename
+ or die "Failed to open '$compose_filename' for reading: $!";
my $need_8bit_cte = file_has_nonascii($compose_filename);
my $in_body = 0;
- my $summary_empty = 1;
- while(<C>) {
+ while(<$compose_file>) {
next if m/^GIT:/;
- if ($in_body) {
- $summary_empty = 0 unless (/^\n$/);
+ if ($in_body && not /^\n$/) {
+ $compose_final_is_not_empty = 1;
} elsif (/^\n$/) {
$in_body = 1;
if ($need_8bit_cte) {
- print C2 "MIME-Version: 1.0\n",
+ print $compose_final_file "MIME-Version: 1.0\n",
"Content-Type: text/plain; ",
"charset=utf-8\n",
"Content-Transfer-Encoding: 8bit\n";
@@ -597,15 +616,12 @@ EOT
print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
next;
}
- print C2 $_;
- }
- close(C);
- close(C2);
- if ($summary_empty) {
- print "Summary email is empty, skipping it\n";
- $compose = -1;
+ print $compose_final_file $_;
}
+
+ print "Summary email is empty, skipping it\n" unless ($compose_final_is_not_empty);
+
} elsif ($annotate) {
do_edit(@files);
}
@@ -685,9 +701,7 @@ if (!defined $smtp_server) {
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
-if ($compose && $compose > 0) {
- @files = ($compose_filename . ".final", @files);
-}
+unshift(@files, $compose_final_filename) if ($compose_final_is_not_empty);
# Variables we set as part of the loop over files
our ($message_id, %mail, $subject, $reply_to, $references, $message,
@@ -1153,7 +1167,13 @@ for (my $index = 0; $index < @files; $index++) {
cleanup_compose_files();
sub cleanup_compose_files() {
- unlink($compose_filename, $compose_filename . ".final") if $compose;
+ if (defined $compose) {
+ unlink(
+ $compose_final_filename,
+ # Don't delete user-supplied file.
+ $compose ? () : $compose_filename
+ );
+ }
}
$smtp->quit if $smtp;
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* [PATCH RFC 3/6] send-email: Handle "GIT:" rather than "GIT: " during --compose
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1239139522-24118-2-git-send-email-mfwitten@gmail.com>
This should make things a little more robust in terms of user input;
before, even the program got it wrong by outputting a line with only
"GIT:", which was left in place as a header, because there would be
no following space character.
Also, I cleaned up get_patch_subject().
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-send-email.perl | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 63d6063..098c620 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -505,15 +505,16 @@ if (@files) {
}
sub get_patch_subject($) {
- my $fn = shift;
- open (my $fh, '<', $fn);
- while (my $line = <$fh>) {
- next unless ($line =~ /^Subject: (.*)$/);
- close $fh;
- return "GIT: $1\n";
+
+ my $patch = shift;
+ open (my $fh, '<', $patch);
+
+ while (<$fh>) {
+ next unless (/^Subject: (.*)$/);
+ return $1;
}
- close $fh;
- die "No subject line in $fn ?";
+
+ die "'Subject:' line expected in '$patch'";
}
if ($compose) {
@@ -532,7 +533,7 @@ if ($compose) {
print C <<EOT;
From $tpl_sender # This line is ignored.
-GIT: Lines beginning in "GIT: " will be removed.
+GIT: Lines beginning in "GIT:" will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
GIT:
@@ -543,7 +544,7 @@ In-Reply-To: $tpl_reply_to
EOT
for my $f (@files) {
- print C get_patch_subject($f);
+ print C "GIT: ", get_patch_subject($f), "\n";
}
close(C);
@@ -565,7 +566,7 @@ EOT
my $in_body = 0;
my $summary_empty = 1;
while(<C>) {
- next if m/^GIT: /;
+ next if m/^GIT:/;
if ($in_body) {
$summary_empty = 0 unless (/^\n$/);
} elsif (/^\n$/) {
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* [PATCH RFC 2/6] send-email: --smtp-server-port should take an integer
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
In-Reply-To: <1239139522-24118-1-git-send-email-mfwitten@gmail.com>
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 273c8c7..63d6063 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -251,7 +251,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"chain-reply-to!" => \$chain_reply_to,
"delay=i" => \$delay,
"smtp-server=s" => \$smtp_server,
- "smtp-server-port=s" => \$smtp_server_port,
+ "smtp-server-port=i" => \$smtp_server_port,
"smtp-user=s" => \$smtp_authuser,
"smtp-pass:s" => \$smtp_authpass,
"smtp-ssl" => sub { $smtp_encryption = 'ssl' },
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* [PATCH RFC 1/6] send-email: Add --delay for separating emails
From: Michael Witten @ 2009-04-07 21:25 UTC (permalink / raw)
To: git
When sending a patch series, the emails often arrive at the final
destination out of order; though these emails should be chained
via the In-Reply-To headers, some mail-viewing systems display
by order of arrival instead.
The --delay option provides a means for specifying that there
should be a certain number of seconds of delay between sending
emails, so that the arrival order can be controlled better.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
Documentation/git-send-email.txt | 5 +++++
git-send-email.perl | 17 +++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 10dfd66..4b656ca 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -97,6 +97,11 @@ The --to option must be repeated for each user you want on the to list.
Sending
~~~~~~~
+--delay::
+ Specify the minimum number of seconds of delay that should occur
+ between sending emails. This number should be an integer >= zero.
+ Default is the value of the 'sendemail.delay' configuration variable.
+
--envelope-sender::
Specify the envelope sender used to send the emails.
This is useful if your default address is not the address that is
diff --git a/git-send-email.perl b/git-send-email.perl
index 172b53c..273c8c7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -56,6 +56,7 @@ git send-email [options] <file | directory | rev-list options >
--compose * Open an editor for introduction.
Sending:
+ --delay <int> * Delay (seconds) between sending emails.
--envelope-sender <str> * Email envelope sender.
--smtp-server <str:int> * Outgoing SMTP server to use. The port
is optional. Default 'localhost'.
@@ -180,7 +181,7 @@ sub do_edit {
}
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
+my ($delay, $thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate, $confirm);
@@ -196,6 +197,7 @@ my %config_bool_settings = (
);
my %config_settings = (
+ "delay" => \$delay,
"smtpserver" => \$smtp_server,
"smtpserverport" => \$smtp_server_port,
"smtpuser" => \$smtp_authuser,
@@ -247,6 +249,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"cc=s" => \@initial_cc,
"bcc=s" => \@bcclist,
"chain-reply-to!" => \$chain_reply_to,
+ "delay=i" => \$delay,
"smtp-server=s" => \$smtp_server,
"smtp-server-port=s" => \$smtp_server_port,
"smtp-user=s" => \$smtp_authuser,
@@ -973,8 +976,9 @@ $references = $initial_reply_to || '';
$subject = $initial_subject;
$message_num = 0;
-foreach my $t (@files) {
- open(F,"<",$t) or die "can't open file $t";
+for (my $index = 0; $index < @files; $index++) {
+ my $file = $files[$index];
+ open(F,"<",$file) or die "can't open file $file";
my $author = undef;
my $author_encoding;
@@ -1083,7 +1087,7 @@ foreach my $t (@files) {
close F;
if (defined $cc_cmd && !$suppress_cc{'cccmd'}) {
- open(F, "$cc_cmd $t |")
+ open(F, "$cc_cmd $file |")
or die "(cc-cmd) Could not execute '$cc_cmd'";
while(<F>) {
my $c = $_;
@@ -1128,6 +1132,11 @@ foreach my $t (@files) {
send_message();
+ if ($delay && $index < $#files) {
+ my $this_long = $delay;
+ while (($this_long -= sleep $this_long) > 0) {}
+ }
+
# set up for the next message
if ($chain_reply_to || !defined $reply_to || length($reply_to) == 0) {
$reply_to = $message_id;
--
1.6.2.2.448.g61445.dirty
^ permalink raw reply related
* Re: Performance issue: initial git clone causes massive repack
From: Björn Steinbrink @ 2009-04-07 20:35 UTC (permalink / raw)
To: Jeff King
Cc: Nicolas Pitre, Jakub Narebski, Sverre Rabbelier, david,
Junio C Hamano, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List
In-Reply-To: <20090407202954.GA13501@coredump.intra.peff.net>
On 2009.04.07 16:29:54 -0400, Jeff King wrote:
> On Tue, Apr 07, 2009 at 08:12:59PM +0200, Björn Steinbrink wrote:
>
> > If so, that doesn't look it it's going to work out as easily as one
> > would hope. Robin said that both processes, git-upload-pack (which does
> > the rev-list) and pack-objects peaked at ~2GB of RSS (which probably
> > includes the mmapped packs). But the above pack-objects with --all peaks
>
> I thought he said this, too, but look at the ps output he posted here:
>
> http://article.gmane.org/gmane.comp.version-control.git/115739
>
> It clearly shows upload-pack with a tiny RSS, and pack-objects doing all
> of the damage.
That second git-upload-pack is the interesting one. upload-pack forks to
do the rev-list stuff, without changing its process name, so it keeps
being listed as upload-pack. And as the process already died, its
RSS/VZS dropped to zero.
Björn
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Jeff King @ 2009-04-07 20:29 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Nicolas Pitre, Jakub Narebski, Sverre Rabbelier, david,
Junio C Hamano, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List
In-Reply-To: <20090407181259.GB4413@atjola.homenet>
On Tue, Apr 07, 2009 at 08:12:59PM +0200, Björn Steinbrink wrote:
> If so, that doesn't look it it's going to work out as easily as one
> would hope. Robin said that both processes, git-upload-pack (which does
> the rev-list) and pack-objects peaked at ~2GB of RSS (which probably
> includes the mmapped packs). But the above pack-objects with --all peaks
I thought he said this, too, but look at the ps output he posted here:
http://article.gmane.org/gmane.comp.version-control.git/115739
It clearly shows upload-pack with a tiny RSS, and pack-objects doing all
of the damage.
-Peff
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Björn Steinbrink @ 2009-04-07 20:27 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jakub Narebski, Sverre Rabbelier, david, Junio C Hamano,
Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0904071454250.6741@xanadu.home>
On 2009.04.07 14:56:41 -0400, Nicolas Pitre wrote:
> On Tue, 7 Apr 2009, Björn Steinbrink wrote:
>
> > On 2009.04.07 13:48:02 -0400, Nicolas Pitre wrote:
> > > The first low hanging fruit to help this case is to make upload-pack use
> > > the --revs argument with pack-object to let it do the object enumeration
> > > itself directly, instead of relying on the rev-list output through a
> > > pipe. This is what 'git repack' does already. pack-objects has to
> > > access the pack anyway, so this would eliminate an extra access from a
> > > different process.
> >
> > Hm, for an initial clone that would end up as:
> > git pack-objects --stdout --all
> > right?
> >
> > If so, that doesn't look it it's going to work out as easily as one
> > would hope. Robin said that both processes, git-upload-pack (which does
> > the rev-list) and pack-objects peaked at ~2GB of RSS (which probably
> > includes the mmapped packs). But the above pack-objects with --all peaks
> > at 3.1G here, so it basically seems to keep all the stuff in memory that
> > the individual processes had. But this way, it's all at once, not 2G
> > first and then 2G in a second process, after the first one exitted.
>
> Right, and it is probably faster too.
>
> Can I get a copy of that repository somewhere?
http://git.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
At least that's what I cloned ;-) I hope it's the right one, but it fits
the description...
Björn
^ permalink raw reply
* Re: Showing the version of a file that's in the Index.
From: Tim Visher @ 2009-04-07 20:15 UTC (permalink / raw)
To: Teemu Likonen; +Cc: markus.heidelberg, Git Mailing List
In-Reply-To: <874ox0w7ak.fsf@iki.fi>
On Tue, Apr 7, 2009 at 4:14 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
> On 2009-04-07 22:10 (+0200), Markus Heidelberg wrote:
>
>> Tim Visher, 07.04.2009:
>>> How do you go about showing the version of the file that's in an
>>> index.
>>
>> With version do you mean content? Then
>>
>> git cat-file -p :0:file
>> or
>> git cat-file -p :file
>
> Or
>
> git show :file
>
Nice. Thank you!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Showing the version of a file that's in the Index.
From: Teemu Likonen @ 2009-04-07 20:14 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <200904072210.05591.markus.heidelberg@web.de>
On 2009-04-07 22:10 (+0200), Markus Heidelberg wrote:
> Tim Visher, 07.04.2009:
>> How do you go about showing the version of the file that's in an
>> index.
>
> With version do you mean content? Then
>
> git cat-file -p :0:file
> or
> git cat-file -p :file
Or
git show :file
^ permalink raw reply
* Re: Showing the version of a file that's in the Index.
From: Markus Heidelberg @ 2009-04-07 20:10 UTC (permalink / raw)
To: Tim Visher; +Cc: Git Mailing List
In-Reply-To: <c115fd3c0904071259y53b4b264u9c9957b68e36cc44@mail.gmail.com>
Tim Visher, 07.04.2009:
> How do you go about showing the version of the file that's in an
> index.
With version do you mean content? Then
git cat-file -p :0:file
or
git cat-file -p :file
See git-rev-parse(1) "Specifying revisions", the last item.
Markus
^ permalink raw reply
* Showing the version of a file that's in the Index.
From: Tim Visher @ 2009-04-07 19:59 UTC (permalink / raw)
To: Git Mailing List
Hello Everyone,
How do you go about showing the version of the file that's in an
index. I'm currently going through a somewhat convoluted in-file
add/commit process and I'd like to verify that what I'm about to
commit is in fact the version that I want to commit.
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] mailmap: resurrect lower-casing of email addresses
From: Markus Heidelberg @ 2009-04-07 19:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0904071315460.6897@intel-tinevez-2-302>
Johannes Schindelin, 07.04.2009:
> Hi,
>
> On Mon, 6 Apr 2009, A Large Angry SCM wrote:
>
> > s/Germany and Munich/Berlin and Munich/
>
> Cool! Berlin is only 2 hours from my home, so let's meet there!
>
> We could even use the opportunity for a little informal German
> GitTogether... "Alles wird Git!"?
Damn, why only is Berlin on the other end of Germany compared to where I
live?
Nice slogan, BTW.
Markus
^ permalink raw reply
* Re: git over http not re-authenticating after 301 redirect?
From: Paul Vincent Craven @ 2009-04-07 19:25 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0904071041200.5901@localhost.localdomain>
On Tue, Apr 7, 2009 at 2:42 AM, Martin Storsjö <martin@martin.st> wrote:
> It's a long shot, but try see if you can upgrade to a newer version of
> libcurl; I think I saw some issue like this when I was experimenting with
> different http auth setups last week, that was solved by using newer
> versions...
No luck, but thanks for the suggestion. Updating to the March 3 build
of curl 7.19.4 yielded the same results.
--
Paul Vincent Craven
http://www.cravenfamily.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox