* Re: [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-24 15:57 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20071224111822.GA10356@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
Woops I borked the mail, the subject was supposed to be:
Subject: [PATCH] Add a --(no-)undefined option to git-name-rev.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <476F8679.8010706@qumranet.com>
Avi Kivity wrote:
> Junio C Hamano wrote:
>>> Well, my use case is different. All of the development merges are
>>> fast-forwards (or plain patch applications); the only multiple-parent
>>> merges are pulls I do from the main tree in order to advance the
>>> baseline,...
>>>
>>
>> Yeah, that is what I meant as a special case. If you submit
>> patches and rebase the remainder of your changes to the updated
>> upstream (as x.org folks seem to do), then the --first-parent
>> history will not be your own development but "the global trunk
>> history." If you are the top-level maintainer and your pull
>> sometimes ends up as a fast forward and sometimes a real merge,
>> you will sometimes get a full history of a topic done by
>> somebody else (if that person rebased on top of you) or just a
>> summary single merge (otherwise), and the distinction between
>> these two cases does not have anything to do with whose commits
>> they are (i.e. mine vs others) or the scope of the changes
>> (i.e. the trunk history vs side branch development). It would
>> not be as useful as the "looking at the list of one's own
>> commits while summarizing out others' developments as merge
>> commits" world view the --first-parent would give you in your
>> history.
>>
>
> Sorry, I'm confused now. I'll try to explain more carefully what I'm
> doing.
>
> I'm a mid-level maintainer for a particular subsystem (kvm). I merge
> patchsets from others and do my own work, but I am careful to keep
> everything linear (no real merges in the git sense). Every once in a
> while I merge from upstream or some other tree, but these are never
> kvm developments. Every merge window I rebase the development branch
> to upstream, removing commits that were later reverted, and merging
> fixes into the patches that introduce them and push the result to
> Linus. Hopefully that's clear as I'm not much of an ascii artist.
>
> So, for me --first-parent means "commits to the development branch of
> kvm", whether by myself or someone else. It specifically excludes kvm
> commits to mainline, since that would result in a bunch of duplicated
> commits. But it seems to be quite different from what you're describing.
>
Anyway, here's what I came up with:
--first-parent::
Follow only the first parent commit upon seeing a merge
commit. This option gives a better overview of the
evolution of a particular branch.
Note that this is only useful if the branch implements a consistent
fast-forward merge policy. One example is to never do a fast-forward
merge (so that --first-parent returns strictly local commits). Another
possible policy is to always fast-forward development related to the
branch's
topic, and only merge synchronizations with upstream or with other
topic branches.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Johannes Schindelin @ 2007-12-24 17:38 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <8763yof9lg.fsf@gollum.intra.norang.ca>
Hi,
On Mon, 24 Dec 2007, Bernt Hansen wrote:
> git rebase --interactive formats the combined commit log message
> incorrectly when squashing 3 or more commits which have no newline on
> the last line of the commit message.
This is a patch for git-gui, so why not make that clear in the subject?
(And I have a hunch that Shawn would have liked the patch relative to
git-gui.git, not git.git...)
Further, there are other tools than rebase -i that like commit messages
better when terminated by a newline, and _that_ is what I would like to
read in the commit message for this patch.
If nobody is quicker, I'll try to fix the problem on the rebase -i side in
a few days.
Thanks,
Dscho
^ permalink raw reply
* [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: David Brown @ 2007-12-24 19:01 UTC (permalink / raw)
To: git
In-Reply-To: <1198216860-487-1-git-send-email-git@davidb.org>
There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc. However,
there are other times that git-send-email automatically includes Cc'd
recipients. This is not desirable for all development environments.
Add a new option --suppress-cc, which can be specified one or more times to
list the categories of auto-cc fields that should be suppressed. If not
specified, it defaults to values to give the same behavior as specified
by --suppress-from, and --signed-off-cc. The categories are:
self - patch sender. Same as --suppress-from.
author - patch author.
cc - cc lines mentioned in the patch.
cccmd - avoid running the cccmd.
sob - signed off by lines.
Signed-off-by: David Brown <git@davidb.org>
---
I tried to generalize as suggested in Junio's email, but it just didn't fit
well with the decision tree in the code.
What bothers me most about this change is that --signed-of-cc
and --suppress-from are silently ignored if --suppress-cc is given, either
on the command line, or in the config.
Documentation/git-send-email.txt | 13 +++++++++++++
git-send-email.perl | 34 ++++++++++++++++++++++++++++++----
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index f0bd285..432f336 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -70,6 +70,7 @@ The --cc option must be repeated for each user you want on the cc list.
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
+ Note that this has no effect if --suppress-cc is given.
--quiet::
Make git-send-email less verbose. One line per email should be
@@ -116,6 +117,18 @@ The --cc option must be repeated for each user you want on the cc list.
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
+ Note that this has no effect if --suppress-cc is given.
+
+--suppress-cc::
+ Specify an additional category of recipients to suppress the
+ auto-cc of. 'self' will avoid including the sender, 'author' will
+ avoid including the patch author, 'cc' will avoid including anyone
+ mentioned in Cc lines in the patch, 'sob' will avoid including
+ anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
+ running the --cc-cmd.
+ Default is the value of 'sendemail.suppresscc' configuration value;
+ if that is unspecified, default to 'self' if --suppress-from is
+ specified, as well as 'sob' if --no-signed-off-cc is specified.
--thread, --no-thread::
If this is set, the In-Reply-To header will be set on each email sent.
diff --git a/git-send-email.perl b/git-send-email.perl
index e47994a..cb9adf2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -88,6 +88,11 @@ Options:
--smtp-ssl If set, connects to the SMTP server using SSL.
+ --suppress-cc Suppress the specified category of auto-CC. The category
+ can be one of 'author' for the patch author, 'self' to
+ avoid copying yourself, 'sob' for Signed-off-by lines,
+ and 'cccmd' for the output of the cccmd.
+
--suppress-from Suppress sending emails to yourself. Defaults to off.
--thread Specify that the "In-Reply-To:" header should be set on all
@@ -177,6 +182,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
+my (@suppress_cc);
my %config_bool_settings = (
"thread" => [\$thread, 1],
@@ -196,6 +202,7 @@ my %config_settings = (
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
"aliasesfile" => \@alias_files,
+ "suppresscc" => \@suppress_cc,
);
# Begin by accumulating all the variables (defined above), that we will end up
@@ -218,6 +225,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"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_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
@@ -262,6 +270,20 @@ foreach my $setting (values %config_bool_settings) {
${$setting->[0]} = $setting->[1] unless (defined (${$setting->[0]}));
}
+# Set CC suppressions
+my(%suppress_cc);
+if (@suppress_cc) {
+ foreach my $entry (@suppress_cc) {
+ die "Unknown --suppress-cc field: '$entry'\n"
+ unless $entry =~ /^(cccmd|cc|author|self|sob)$/;
+ $suppress_cc{$entry} = 1;
+ }
+} else {
+ # Convert the old-style options.
+ $suppress_cc{'self'} = 1 if $suppress_from;
+ $suppress_cc{'sob'} = 1 unless $signed_off_cc;
+}
+
my ($repoauthor) = $repo->ident_person('author');
my ($repocommitter) = $repo->ident_person('committer');
@@ -701,11 +723,14 @@ foreach my $t (@files) {
} elsif (/^(Cc|From):\s+(.*)$/) {
if (unquote_rfc2047($2) eq $sender) {
- next if ($suppress_from);
+ next if ($suppress_cc{'self'});
}
elsif ($1 eq 'From') {
($author, $author_encoding)
= unquote_rfc2047($2);
+ next if ($suppress_cc{'author'});
+ } else {
+ next if ($suppress_cc{'cc'});
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
@@ -732,7 +757,7 @@ foreach my $t (@files) {
# line 2 = subject
# So let's support that, too.
$input_format = 'lots';
- if (@cc == 0) {
+ if (@cc == 0 && !$suppress_cc{'cc'}) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
$_, $_) unless $quiet;
@@ -750,9 +775,10 @@ foreach my $t (@files) {
} else {
$message .= $_;
if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
+ next if ($suppress_cc{'sob'});
my $c = $2;
chomp $c;
- next if ($c eq $sender and $suppress_from);
+ next if ($c eq $sender and $suppress_cc{'self'});
push @cc, $c;
printf("(sob) Adding cc: %s from line '%s'\n",
$c, $_) unless $quiet;
@@ -761,7 +787,7 @@ foreach my $t (@files) {
}
close F;
- if (defined $cc_cmd) {
+ if (defined $cc_cmd && !$suppress_cc{'cccmd'}) {
open(F, "$cc_cmd $t |")
or die "(cc-cmd) Could not execute '$cc_cmd'";
while(<F>) {
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: Joel Becker @ 2007-12-24 21:03 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <1198522902-12117-1-git-send-email-git@davidb.org>
On Mon, Dec 24, 2007 at 11:01:42AM -0800, David Brown wrote:
> There are a few options to git-send-email to suppress the automatic
> generation of 'Cc' fields: --suppress-from, and --signed-off-cc. However,
> there are other times that git-send-email automatically includes Cc'd
> recipients. This is not desirable for all development environments.
>
> Add a new option --suppress-cc, which can be specified one or more times to
> list the categories of auto-cc fields that should be suppressed. If not
> specified, it defaults to values to give the same behavior as specified
> by --suppress-from, and --signed-off-cc. The categories are:
>
> self - patch sender. Same as --suppress-from.
> author - patch author.
> cc - cc lines mentioned in the patch.
> cccmd - avoid running the cccmd.
> sob - signed off by lines.
+ all - all of the above, thus only honoring '--to', '--cc', and
'--bcc'
Joel
--
"The nice thing about egotists is that they don't talk about other
people."
- Lucille S. Harper
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* [PATCH] git-send-email: Add --suppress-cc all
From: David Brown @ 2007-12-24 21:26 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20071224210325.GA7242@mail.oracle.com>
Add the 'all' option to --suppress-cc, allowing easier suppression of
everything.
Signed-off-by: David Brown <git@davidb.org>
---
On Mon, Dec 24, 2007 at 01:03:25PM -0800, Joel Becker wrote:
>+ all - all of the above, thus only honoring '--to', '--cc', and
> '--bcc'
I can squash this with the other patch if that would be cleaner.
Dave
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 11 ++++++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 432f336..fdfb56e 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -125,7 +125,7 @@ The --cc option must be repeated for each user you want on the cc list.
avoid including the patch author, 'cc' will avoid including anyone
mentioned in Cc lines in the patch, 'sob' will avoid including
anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
- running the --cc-cmd.
+ running the --cc-cmd. 'all' will suppress all auto cc values.
Default is the value of 'sendemail.suppresscc' configuration value;
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
diff --git a/git-send-email.perl b/git-send-email.perl
index cb9adf2..ef16824 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -275,7 +275,7 @@ my(%suppress_cc);
if (@suppress_cc) {
foreach my $entry (@suppress_cc) {
die "Unknown --suppress-cc field: '$entry'\n"
- unless $entry =~ /^(cccmd|cc|author|self|sob)$/;
+ unless $entry =~ /^(all|cccmd|cc|author|self|sob)$/;
$suppress_cc{$entry} = 1;
}
} else {
@@ -284,6 +284,15 @@ if (@suppress_cc) {
$suppress_cc{'sob'} = 1 unless $signed_off_cc;
}
+if ($suppress_cc{'all'}) {
+ foreach my $entry (qw (ccmd cc author self sob)) {
+ $suppress_cc{$entry} = 1;
+ }
+ delete $suppress_cc{'all'};
+}
+
+printf "Suppressions: %s\n", join(',', keys(%suppress_cc));
+
my ($repoauthor) = $repo->ident_person('author');
my ($repocommitter) = $repo->ident_person('committer');
--
1.5.3.7
^ permalink raw reply related
* [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: David Brown @ 2007-12-24 21:36 UTC (permalink / raw)
To: git; +Cc: Joel Becker
In-Reply-To: <1198216860-487-1-git-send-email-git@davidb.org>
There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc.
However, there are other times that git-send-email automatically
includes Cc'd recipients. This is not desirable for all development
environments.
Add a new option --suppress-cc, which can be specified one or more
times to list the categories of auto-cc fields that should be
suppressed. If not specified, it defaults to values to give the same
behavior as specified by --suppress-from, and --signed-off-cc. The
categories are:
self - patch sender. Same as --suppress-from.
author - patch author.
cc - cc lines mentioned in the patch.
cccmd - avoid running the cccmd.
sob - signed off by lines.
all - all non-explicit recipients
Signed-off-by: David Brown <git@davidb.org>
---
Adds the 'all' category suggested by Joel Becker.
Documentation/git-send-email.txt | 13 +++++++++++
git-send-email.perl | 42 ++++++++++++++++++++++++++++++++++---
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index f0bd285..fdfb56e 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -70,6 +70,7 @@ The --cc option must be repeated for each user you want on the cc list.
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
+ Note that this has no effect if --suppress-cc is given.
--quiet::
Make git-send-email less verbose. One line per email should be
@@ -116,6 +117,18 @@ The --cc option must be repeated for each user you want on the cc list.
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
+ Note that this has no effect if --suppress-cc is given.
+
+--suppress-cc::
+ Specify an additional category of recipients to suppress the
+ auto-cc of. 'self' will avoid including the sender, 'author' will
+ avoid including the patch author, 'cc' will avoid including anyone
+ mentioned in Cc lines in the patch, 'sob' will avoid including
+ anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
+ running the --cc-cmd. 'all' will suppress all auto cc values.
+ Default is the value of 'sendemail.suppresscc' configuration value;
+ if that is unspecified, default to 'self' if --suppress-from is
+ specified, as well as 'sob' if --no-signed-off-cc is specified.
--thread, --no-thread::
If this is set, the In-Reply-To header will be set on each email sent.
diff --git a/git-send-email.perl b/git-send-email.perl
index e47994a..00a7ffc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -88,6 +88,12 @@ Options:
--smtp-ssl If set, connects to the SMTP server using SSL.
+ --suppress-cc Suppress the specified category of auto-CC. The category
+ can be one of 'author' for the patch author, 'self' to
+ avoid copying yourself, 'sob' for Signed-off-by lines,
+ 'cccmd' for the output of the cccmd, or 'all' to suppress
+ all of these.
+
--suppress-from Suppress sending emails to yourself. Defaults to off.
--thread Specify that the "In-Reply-To:" header should be set on all
@@ -177,6 +183,7 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
+my (@suppress_cc);
my %config_bool_settings = (
"thread" => [\$thread, 1],
@@ -196,6 +203,7 @@ my %config_settings = (
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
"aliasesfile" => \@alias_files,
+ "suppresscc" => \@suppress_cc,
);
# Begin by accumulating all the variables (defined above), that we will end up
@@ -218,6 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"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_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
@@ -262,6 +271,27 @@ foreach my $setting (values %config_bool_settings) {
${$setting->[0]} = $setting->[1] unless (defined (${$setting->[0]}));
}
+# Set CC suppressions
+my(%suppress_cc);
+if (@suppress_cc) {
+ foreach my $entry (@suppress_cc) {
+ die "Unknown --suppress-cc field: '$entry'\n"
+ unless $entry =~ /^(all|cccmd|cc|author|self|sob)$/;
+ $suppress_cc{$entry} = 1;
+ }
+} else {
+ # Convert the old-style options.
+ $suppress_cc{'self'} = 1 if $suppress_from;
+ $suppress_cc{'sob'} = 1 unless $signed_off_cc;
+}
+
+if ($suppress_cc{'all'}) {
+ foreach my $entry (qw (ccmd cc author self sob)) {
+ $suppress_cc{$entry} = 1;
+ }
+ delete $suppress_cc{'all'};
+}
+
my ($repoauthor) = $repo->ident_person('author');
my ($repocommitter) = $repo->ident_person('committer');
@@ -701,11 +731,14 @@ foreach my $t (@files) {
} elsif (/^(Cc|From):\s+(.*)$/) {
if (unquote_rfc2047($2) eq $sender) {
- next if ($suppress_from);
+ next if ($suppress_cc{'self'});
}
elsif ($1 eq 'From') {
($author, $author_encoding)
= unquote_rfc2047($2);
+ next if ($suppress_cc{'author'});
+ } else {
+ next if ($suppress_cc{'cc'});
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
@@ -732,7 +765,7 @@ foreach my $t (@files) {
# line 2 = subject
# So let's support that, too.
$input_format = 'lots';
- if (@cc == 0) {
+ if (@cc == 0 && !$suppress_cc{'cc'}) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
$_, $_) unless $quiet;
@@ -750,9 +783,10 @@ foreach my $t (@files) {
} else {
$message .= $_;
if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
+ next if ($suppress_cc{'sob'});
my $c = $2;
chomp $c;
- next if ($c eq $sender and $suppress_from);
+ next if ($c eq $sender and $suppress_cc{'self'});
push @cc, $c;
printf("(sob) Adding cc: %s from line '%s'\n",
$c, $_) unless $quiet;
@@ -761,7 +795,7 @@ foreach my $t (@files) {
}
close F;
- if (defined $cc_cmd) {
+ if (defined $cc_cmd && !$suppress_cc{'cccmd'}) {
open(F, "$cc_cmd $t |")
or die "(cc-cmd) Could not execute '$cc_cmd'";
while(<F>) {
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] git-send-email: Add --suppress-cc all
From: Joel Becker @ 2007-12-24 21:59 UTC (permalink / raw)
To: git
In-Reply-To: <20071224212648.GA21070@old.davidb.org>
On Mon, Dec 24, 2007 at 01:26:48PM -0800, David Brown wrote:
> Add the 'all' option to --suppress-cc, allowing easier suppression of
> everything.
Thank you!
>
> Signed-off-by: David Brown <git@davidb.org>
> ---
> On Mon, Dec 24, 2007 at 01:03:25PM -0800, Joel Becker wrote:
>
>> + all - all of the above, thus only honoring '--to', '--cc', and
>> '--bcc'
>
> I can squash this with the other patch if that would be cleaner.
>
> Dave
>
> Documentation/git-send-email.txt | 2 +-
> git-send-email.perl | 11 ++++++++++-
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 432f336..fdfb56e 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -125,7 +125,7 @@ The --cc option must be repeated for each user you want on the cc list.
> avoid including the patch author, 'cc' will avoid including anyone
> mentioned in Cc lines in the patch, 'sob' will avoid including
> anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
> - running the --cc-cmd.
> + running the --cc-cmd. 'all' will suppress all auto cc values.
> Default is the value of 'sendemail.suppresscc' configuration value;
> if that is unspecified, default to 'self' if --suppress-from is
> specified, as well as 'sob' if --no-signed-off-cc is specified.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index cb9adf2..ef16824 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -275,7 +275,7 @@ my(%suppress_cc);
> if (@suppress_cc) {
> foreach my $entry (@suppress_cc) {
> die "Unknown --suppress-cc field: '$entry'\n"
> - unless $entry =~ /^(cccmd|cc|author|self|sob)$/;
> + unless $entry =~ /^(all|cccmd|cc|author|self|sob)$/;
> $suppress_cc{$entry} = 1;
> }
> } else {
> @@ -284,6 +284,15 @@ if (@suppress_cc) {
> $suppress_cc{'sob'} = 1 unless $signed_off_cc;
> }
> +if ($suppress_cc{'all'}) {
> + foreach my $entry (qw (ccmd cc author self sob)) {
> + $suppress_cc{$entry} = 1;
> + }
> + delete $suppress_cc{'all'};
> +}
> +
> +printf "Suppressions: %s\n", join(',', keys(%suppress_cc));
> +
> my ($repoauthor) = $repo->ident_person('author');
> my ($repocommitter) = $repo->ident_person('committer');
>
> --
> 1.5.3.7
>
--
"Can any of you seriously say the Bill of Rights could get through
Congress today? It wouldn't even get out of committee."
- F. Lee Bailey
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Shawn O. Pearce @ 2007-12-25 4:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bernt Hansen, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712241835210.14355@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 24 Dec 2007, Bernt Hansen wrote:
>
> > git rebase --interactive formats the combined commit log message
> > incorrectly when squashing 3 or more commits which have no newline on
> > the last line of the commit message.
>
> This is a patch for git-gui, so why not make that clear in the subject?
> (And I have a hunch that Shawn would have liked the patch relative to
> git-gui.git, not git.git...)
Indeed.
Most git-gui changes have a subject that starts with "git-gui:" so
its clear in both the email and in the commit log that the change is
a git-gui change. Remember, git-gui's logs show up in the core Git
logs (as its merged with -s subtree) so having that git-gui: prefix
does help people to localize the change within the overall suite.
git-am -3 does a reasonable job at correcting patches that are like
this one is (that aren't relative to git-gui.git) so that's less
of an issue for me. And what git-am -3 cannot correct git-apply
-p2 usually does. If that can't fix the patch then I'll usually
throw it back as its then most likely a true conflict.
> Further, there are other tools than rebase -i that like commit messages
> better when terminated by a newline, and _that_ is what I would like to
> read in the commit message for this patch.
Hmmph. For that reason alone I'm tempted to *not* apply Bernt's
patch.
There is nothing that requires that a commit object end with an LF.
So tools that make this assumption (that there is a trailing LF)
while processing the body of a commit message are quite simply
broken.
Its easy in fast-import to generate commits without a trailing LF.
Or in many text editors its possible to save a file with no trailing
LF on the last line. My favorite VI clone does that; if the file
doesn't end with an LF when it opens its *damned* hard to get a
trailing LF onto that last line. And yes, that's the editor I use
for commit messages when I'm not using git-gui.
IMHO git-gui is producing valid commit messages, and always does
so with no trailing LF, and any tool that is assuming a trailing
LF is always present is broken.
Keeping git-gui behavior like this actually highlights the other
tools that are broken (here Bernt found git-rebase--interactive).
I'd like to hear Junio's or Linus' two cents on the matter, but
if we really want to say that all commits must end with an LF then
maybe git-commit-tree, git-hash-object and git-fast-import should be
performing that sort of validation before creating such an object in
the ODB. Which is probably a change that shouldn't be made before
1.6.0 as its somewhat likely to break people's existing scripts.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Shawn O. Pearce @ 2007-12-25 4:46 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <8763yof9lg.fsf@gollum.intra.norang.ca>
[... comments for patch in reply to Dscho's reply...]
Bernt Hansen <bernt@alumni.uwaterloo.ca> wrote:
> Sorry I don't have an automated test for git-gui. Are there any?
No. I didn't really build git-gui very well for that sort of thing.
Part of my long-term plan for git-gui is to do refactoring on it
so that we can create automated tests for the lower level parts
(the logic behind the GUI). Then we can actually do some automated
testing.
Wow. I just realized git-gui is almost 14 months old. Its probably
going to be another year before the above said refactoring is
completely finished, but its something that needs to be done if
git-gui is going to survive its terrible twos.
--
Shawn.
^ permalink raw reply
* git-gui 0.9.1 release plans
From: Shawn O. Pearce @ 2007-12-25 4:54 UTC (permalink / raw)
To: git
So git-gui 0.9.1...
I have 12 changes in `master` since 0.9.0 that will be included.
Other than these changes, and maybe Bernt's "always append LF in
commit message" patch, this is what will make up the 0.9.1 release.
I expect 0.9.1 will be the last git-gui release before git 1.5.4
goes final, which means git 1.5.4 will be shipping with 0.9.1.
Translators, testers, etc. please speak up in the next week and a
half and get your patches in if there are any outstanding translation
changes or minor bug fixes that should be included.
I'm on vacation (and completely offline) Jan. 5-13th, so I'd like
to wrap up 0.9.1 by the 4th if I can, as Junio has been targeting
for a mid-Jan release of git 1.5.4.
--- Changes since 0.9.0 ---
Christian Stimming (2):
Update git-gui.pot with latest (few) string additions and changes.
Update German translation. 100% completed.
Johannes Sixt (2):
git-gui: Improve the application icon on Windows.
git-gui: Move frequently used commands to the top of the context menu.
Mark Levedahl (1):
git-gui: Unconditionally use absolute paths with Cygwin
Michele Ballabio (2):
git-gui: fix a typo in lib/commit.tcl
git-gui: update it.po and glossary/it.po
Miklos Vajna (1):
Update Hungarian translation. 100% completed.
Robert Schiele (1):
git-gui: install-sh from automake does not like -m755
Shawn O. Pearce (1):
git-gui: Handle file mode changes (644->755) in diff viewer
brian m. carlson (1):
git-gui: Reorder msgfmt command-line arguments
しらいしななこ (1):
Update ja.po for git-gui
--
Shawn.
^ permalink raw reply
* [PATCH] Improve error messages when int/long cannot be parsed from config
From: Shawn O. Pearce @ 2007-12-25 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If a config file has become mildly corrupted due to a missing LF
we may discover some other option joined up against the end of a
numeric value. For example:
[section]
number = 1auto
where the "auto" flag was meant to occur on the next line, below
"number", but the missing LF has caused it to no longer be its
own option. Instead the word "auto" is parsed as a 'unit factor'
for the value of "number".
Before this change we got the confusing error message:
fatal: unknown unit: 'auto'
which told us nothing about where the problem appeared. Now we get:
fatal: bad config value for 'aninvalid.unit'
which at least points the user in the right direction of where to
search for the incorrectly formatted configuration file.
Noticed by erikh on #git, which received the original error from
a simple `git checkout -b` due to a midly corrupted config.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
config.c | 31 +++++++++++++++++++++----------
t/t1300-repo-config.sh | 17 +++++++++++++++++
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/config.c b/config.c
index 22ff4ce..fa56c70 100644
--- a/config.c
+++ b/config.c
@@ -234,17 +234,23 @@ static int git_parse_file(config_fn_t fn)
die("bad config file line %d in %s", config_linenr, config_file_name);
}
-static unsigned long get_unit_factor(const char *end)
+static int parse_unit_factor(const char *end, unsigned long *val)
{
if (!*end)
return 1;
- else if (!strcasecmp(end, "k"))
- return 1024;
- else if (!strcasecmp(end, "m"))
- return 1024 * 1024;
- else if (!strcasecmp(end, "g"))
- return 1024 * 1024 * 1024;
- die("unknown unit: '%s'", end);
+ else if (!strcasecmp(end, "k")) {
+ *val *= 1024;
+ return 1;
+ }
+ else if (!strcasecmp(end, "m")) {
+ *val *= 1024 * 1024;
+ return 1;
+ }
+ else if (!strcasecmp(end, "g")) {
+ *val *= 1024 * 1024 * 1024;
+ return 1;
+ }
+ return 0;
}
int git_parse_long(const char *value, long *ret)
@@ -252,7 +258,10 @@ int git_parse_long(const char *value, long *ret)
if (value && *value) {
char *end;
long val = strtol(value, &end, 0);
- *ret = val * get_unit_factor(end);
+ unsigned long factor = 1;
+ if (!parse_unit_factor(end, &factor))
+ return 0;
+ *ret = val * factor;
return 1;
}
return 0;
@@ -263,7 +272,9 @@ int git_parse_ulong(const char *value, unsigned long *ret)
if (value && *value) {
char *end;
unsigned long val = strtoul(value, &end, 0);
- *ret = val * get_unit_factor(end);
+ if (!parse_unit_factor(end, &val))
+ return 0;
+ *ret = val;
return 1;
}
return 0;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index e894629..42eac2a 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -448,6 +448,23 @@ test_expect_success numbers '
test z1048576 = "z$m"
'
+cat > expect <<EOF
+fatal: bad config value for 'aninvalid.unit' in .git/config
+EOF
+
+test_expect_success 'invalid unit' '
+
+ git config aninvalid.unit "1auto" &&
+ s=$(git config aninvalid.unit) &&
+ test "z1auto" = "z$s" &&
+ if git config --int --get aninvalid.unit 2>actual
+ then
+ echo config should have failed
+ false
+ fi &&
+ cmp actual expect
+'
+
cat > expect << EOF
true
false
--
1.5.4.rc1.1119.g1e6bc
^ permalink raw reply related
* Re: gitk / git-gui and Tk 8.5 don't play nice together
From: Ismail Dönmez @ 2007-12-25 8:54 UTC (permalink / raw)
To: Kevin Williams; +Cc: git
In-Reply-To: <683a886f0712230702q3cbae65v6d34f44dde520d81@mail.gmail.com>
Sunday 23 December 2007 17:02:04 tarihinde şunları yazmıştınız:
> X Error of failed request: BadMatch (invalid parameter attributes)
> Major opcode of failed request: 152 (RENDER)
> Minor opcode of failed request: 4 (RenderCreatePicture)
> Serial number of failed request: 541
> Current serial number in output stream: 549
>
>
> Is this a known issue? Do I need to file a bug report or something?
Works fine here, But I am on Linux, you didn't mention your platform...
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* Re: [PATCH] Force new line at end of commit message
From: Junio C Hamano @ 2007-12-25 9:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <20071225044202.GO14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I'd like to hear Junio's or Linus' two cents on the matter, but
> if we really want to say that all commits must end with an LF then
> maybe git-commit-tree, git-hash-object and git-fast-import should be
> performing that sort of validation before creating such an object in
> the ODB.
I've so far tried to keep the lowest-level plumbing commit-tree
(and even lower hash-object) without such an artificial limit.
At the lowest level, commit objects should be able to hold any
byte sequence (this includes NUL bytes) as the user wishes.
People who want to use git to implement/experiment a data
structure that may not have anything to do with the usual SCM
should be able to do so using such low-level.
It is a different story about what conventions should Porcelains
enforce. For example, I'd be perfectly happy if git-commit (at
least under its default mode of operation) does not allow NULs
nor incomplete lines in the message, and if git-format-patch and
git-am do not to pass something you cannot e-mail sanely (but
that is only true once we rewrite rebase not to rely on the
pipeline between them). Porcelain level should really make it
easy and safe for the users to work with git as an SCM.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-25 9:35 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <476F8679.8010706@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> I'm a mid-level maintainer for a particular subsystem (kvm). I merge
> patchsets from others and do my own work, but I am careful to keep
> everything linear (no real merges in the git sense). Every once in a
> while I merge from upstream or some other tree, but these are never
> kvm developments. Every merge window I rebase the development branch
> to upstream, removing commits that were later reverted, and merging
> fixes into the patches that introduce them and push the result to
> Linus. Hopefully that's clear as I'm not much of an ascii artist.
> So, for me --first-parent means "commits to the development branch of
> kvm", whether by myself or someone else.
Sure. That's a perfect use case for --first-parent, as you can
afford to rebase.
I wanted to point out that the description needs to be clear
enough that people know the option is applicable only to some
workflow, but not necessarily to their own. Saying "this option
gives a better overview" as if it always would felt wrong. For
example for Linus, the option will not give a better overview.
Even in your case, if you merged from others' kvm tree, the
option becomes useless, as you mentioned ("I am careful to keep
everything linear").
If somebody cannot rebase (Linus certainly doesn't, and as a
general rule the top-level integration branch would never be
rebased) but pulls from people, some merges end up as real
merges while some others fast-forward and do not create merge
commits. In such a history, --first-parent is not very useful.
Some parts of development will see individual commits (i.e. ones
applied by the top-level integrator himself, and the ones built
and committed by a subsystem person whose merge happened to have
fast-forwarded), while other parts will just show merge commits
(i.e. all other merges from subsystem people).
I however think the wording "... the evolution of a particular
branch" lessens my worries a bit, because it hints that the
option is about viewing the history of a topic branch, not the
integration mainline. Maybe the wording can be made even more
explicit and say something like:
This option can give a better overview when viewing the
evolution of a particular topic branch, because merges into
a topic branch tend to be only about adjusting to updated
upstream from time to time, and this option allows you to
ignore the individual commits brought in to your history by
such a merge.
By the way, the wording "if a branch implements a consistent
fast-forward policy" suggests that forcing a real merge when the
merged branch is a fast-forward of your history is somehow a
good thing, but I think it is backwards to make such an
artificial real merge just to keep --first-parent happy.
^ permalink raw reply
* [PATCH] Fix "git log --diff-filter" bug
From: Arjen Laarhoven @ 2007-12-25 11:06 UTC (permalink / raw)
To: gitster; +Cc: git
In commit b7bb760d5ed4881422673d32f869d140221d3564 an optimization
was made to avoid unnecessary diff generation. This was partly fixed
in 99516e35d096f41e7133cacde8fbed8ee9a3ecd0, but obviously the
'--diff-filter' option also needs the diff machinery in action.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
---
revision.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 7e2f4f1..6e85aaa 100644
--- a/revision.c
+++ b/revision.c
@@ -1290,8 +1290,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (revs->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT)
revs->diff = 1;
- /* Pickaxe and rename following needs diffs */
- if (revs->diffopt.pickaxe || DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
+ /* Pickaxe, diff-filter and rename following need diffs */
+ if (revs->diffopt.pickaxe ||
+ revs->diffopt.filter ||
+ DIFF_OPT_TST(&revs->diffopt, FOLLOW_RENAMES))
revs->diff = 1;
if (revs->topo_order)
--
1.5.4.rc1.21.g0e545
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Salikh Zakirov @ 2007-12-25 13:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
Jeff Garzik wrote:
> The kernel hacker's guide to git has received some updates:
> http://linux.yyz.us/git-howto.html
I have some comments on the contents, though I need to warn,
that I've been following git development for about year and a half now,
and I am not a kernel hacker, so my comments may have wrong bias.
> Obtain a diff between current branch, and master branch
>
> In most trees with branches, .git/refs/heads/master contains the
> current 'vanilla' upstream tree, for easy diffing and merging. (in
> trees without branches, 'master' simply contains your latest changes)
>
> $ git diff master..HEAD
IMHO, syntax 'git diff master HEAD' is preferable, in order to avoid
confusion with 'git log master..HEAD' usage, which has quite different
meaning, roughly expressible as
git diff `git merge-base master HEAD` HEAD
for getting one big diff of the changes in HEAD since master)
> (this is equivalent to git diff HEAD, when used with HEAD branch)
This seems incorrect to me, as 'git diff master HEAD' compares two
revisions, while 'git diff HEAD' compares working tree with HEAD revision.
Besides, expression 'HEAD branch' is misleading, because HEAD is not a branch by itself,
but rather a link to the latest state of the current branch.
^ permalink raw reply
* [PATCH] combine-diff: use diff_opts->a_prefix
From: Salikh Zakirov @ 2007-12-25 13:46 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
The introduction of configurable dir prefix for diff headers in commit
eab9a40b 'Teach diff machinery to display other prefixes than "a/" and "b/"'
missed combined diff generation.
Signed-off-by: Salikh Zakirov <salikh@gmail.com>
---
I realize that this fix is ugly, so I am all ears for a suggestion
of a better fix.
combine-diff.c | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index e22db89..5c3b42d 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -646,10 +646,11 @@ static void reuse_combine_diff(struct sline *sline, unsigned long cnt,
sline->p_lno[i] = sline->p_lno[j];
}
-static void dump_quoted_path(const char *prefix, const char *path,
- const char *c_meta, const char *c_reset)
+static void dump_quoted_path(const char *prefix, const char *prefix2,
+ const char *path, const char *c_meta,
+ const char *c_reset)
{
- printf("%s%s", c_meta, prefix);
+ printf("%s%s%s", c_meta, prefix, prefix2);
quote_c_style(path, NULL, stdout, 0);
printf("%s\n", c_reset);
}
@@ -792,7 +793,7 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
if (rev->loginfo && !rev->no_commit_id)
show_log(rev, opt->msg_sep);
- dump_quoted_path(dense ? "diff --cc " : "diff --combined ",
+ dump_quoted_path(dense ? "diff --cc " : "diff --combined ", "",
elem->path, c_meta, c_reset);
printf("%sindex ", c_meta);
for (i = 0; i < num_parent; i++) {
@@ -829,13 +830,15 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
printf("%s\n", c_reset);
}
if (added)
- dump_quoted_path("--- /dev/", "null", c_meta, c_reset);
+ dump_quoted_path("--- /dev/", "", "null", c_meta, c_reset);
else
- dump_quoted_path("--- a/", elem->path, c_meta, c_reset);
+ dump_quoted_path("--- ", opt->a_prefix, elem->path,
+ c_meta, c_reset);
if (deleted)
- dump_quoted_path("+++ /dev/", "null", c_meta, c_reset);
+ dump_quoted_path("+++ /dev/", "", "null", c_meta, c_reset);
else
- dump_quoted_path("+++ b/", elem->path, c_meta, c_reset);
+ dump_quoted_path("+++ ", opt->b_prefix, elem->path,
+ c_meta, c_reset);
dump_sline(sline, cnt, num_parent, DIFF_OPT_TST(opt, COLOR_DIFF));
}
free(result);
--
1.5.3.7.1315.g1b8e7
^ permalink raw reply related
* [PATCH] git-filter-branch could be confused by similar names
From: Dmitry Potapov @ 2007-12-25 14:35 UTC (permalink / raw)
To: git; +Cc: Dmitry Potapov
'git-filter-branch branch' could fail producing the error:
"Which ref do you want to rewrite?" if existed another branch
or tag, which name was 'branch-something' or 'something/branch'.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
git-filter-branch.sh | 2 +-
t/t7003-filter-branch.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index dbab1a9..b89a720 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -219,7 +219,7 @@ do
;;
*)
ref="$(git for-each-ref --format='%(refname)' |
- grep /"$ref")"
+ grep '^refs/[^/]\+/'"$ref"'$')"
esac
git check-ref-format "$ref" && echo "$ref"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 5f60b22..c3e5207 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -36,6 +36,16 @@ test_expect_success 'result is really identical' '
test $H = $(git rev-parse HEAD)
'
+test_expect_success 'rewrite branch with similar names' '
+ git branch my &&
+ git tag my/orig &&
+ git tag my-orig &&
+ git tag orig/my &&
+ git tag orig-my &&
+ git-filter-branch my &&
+ test $H = $(git rev-parse HEAD)
+'
+
test_expect_success 'rewrite, renaming a specific file' '
git-filter-branch -f --tree-filter "mv d doh || :" HEAD
'
--
1.5.3.5
^ permalink raw reply related
* [RFC/PATCH] Add a script to run test scripts using valgrind.
From: Christian Couder @ 2007-12-25 20:29 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
This patch adds a Perl script 'run_valgrind.pl' that runs
the test scripts passed as arguments using valgrind.
To use valgrind, we use a shell alias like:
alias git='valgrind <options> git'
and we source a test script in the same system call.
The valgrind logs are then parsed for errors and the errors
found are hashed so that they appear only once at the end.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/run_valgrind.pl | 138 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 138 insertions(+), 0 deletions(-)
create mode 100755 t/run_valgrind.pl
diff --git a/t/run_valgrind.pl b/t/run_valgrind.pl
new file mode 100755
index 0000000..cb965c9
--- /dev/null
+++ b/t/run_valgrind.pl
@@ -0,0 +1,138 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+# All arguments should be test scripts.
+my @scripts = @ARGV;
+
+my $vg_vers = valgrind_version();
+
+print "Using valgrind version: $vg_vers\n";
+
+my $log_base = '/tmp/vg_log';
+my $log_opt = ($vg_vers < '3.3') ? $log_base : "$log_base.%p";
+my $vg_opts = "--log-file=$log_opt --trace-children=yes";
+my $alias = "alias git='valgrind $vg_opts git'";
+
+# Remove previous log files.
+system("rm -rf $log_base.*");
+
+# Run the scripts using an alias for Git.
+foreach my $file (@scripts) {
+ system("$alias \n . ./$file");
+}
+
+# Error lines from log files.
+my @log_files = glob("$log_base.*");
+my @errs = `grep 'ERROR SUMMARY' $log_base.*`;
+chomp @errs;
+
+print "\nNumber of log files: " . scalar(@log_files) . "\n";
+print "Number of error lines: " . scalar(@errs) . "\n";
+
+my @logs;
+for (@errs) {
+ if (m/^([^:]+):.*ERROR SUMMARY: (\d+) errors/) {
+ push @logs, $1 if ($2 > 0);
+ } else {
+ print STDERR "strange line: $_\n";
+ }
+}
+
+print "\nResulting files with errors:\n\n", join("\n", @logs), "\n\n";
+
+# Parse error files.
+my @info = ();
+for (@logs) {
+ my @new = parse_error_file($_);
+ push @info, @new;
+}
+
+# Get only uniq errors.
+my @uniq = ();
+my %stack = ();
+for (@info) {
+ my $key = stack_info($_, 1);
+ if (exists $stack{$key}) {
+ push @{$stack{$key}}, $_->{file};
+ } else {
+ $stack{$key} = [ $_->{file} ];
+ $_->{file} = $stack{$key};
+ push @uniq, $_;
+ }
+}
+
+# Print uniq errors.
+print "Uniq errors:\n";
+for (@uniq) {
+ print "\n" . stack_info($_);
+ print "Files: " . join(", ", @{$_->{file}}) . "\n";
+}
+
+sub valgrind_version {
+ system("which valgrind > /dev/null 2>&1") == 0
+ or die "'which valgrind' failed.";
+
+ my $version = `valgrind --version`;
+ chomp $version;
+
+ if ($version =~ m/(\d+)\.(\d+)\.(\d+)/) {
+ return "$1.$2";
+ } else {
+ die "Could not find valgrind version.";
+ }
+}
+
+sub stack_info {
+ $_ = shift;
+ my ($key) = @_;
+
+ my $msg = $_->{msg};
+ $msg =~ s/0x[0-9A-F]+// if ($key);
+
+ my @places = map { $_->[1] } @{$_->{stack}};
+ return "$msg\n" . join("\n", @places) . "\n";
+}
+
+sub clean_line {
+ my ($line) = @_;
+
+ $line =~ s/^==\d+==\s+//;
+
+ return $line;
+}
+
+sub parse_error_file {
+ my ($file) = @_;
+
+ # Slurp file.
+ open(IN, "< $file") or die "Could not open '$file' for reading: $!";
+ my @content = <IN>;
+ chomp @content;
+ close IN;
+
+ # Parse errors in file.
+ my @errs = ();
+ my $stack = 0;
+ my $prev = '';
+ my $cur;
+ for (@content) {
+ if (not $stack and m/ at 0x([0-9A-F]+): (.*)$/) {
+ $stack = 1;
+ $cur = { msg => $prev,
+ file => $file,
+ stack => [ [$1, $2] ] };
+ } elsif ($stack) {
+ if (m/ by 0x([0-9A-F]+): (.*)$/) {
+ push @{$cur->{stack}}, [$1, $2];
+ } else {
+ push @errs, $cur;
+ $stack = 0;
+ }
+ }
+ $prev = clean_line($_);
+ }
+
+ return @errs;
+}
--
1.5.3.7.2270.g786cf-dirty
^ permalink raw reply related
* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: Junio C Hamano @ 2007-12-25 21:04 UTC (permalink / raw)
To: David Brown; +Cc: git, Joel Becker
In-Reply-To: <1198532163-25308-1-git-send-email-git@davidb.org>
David Brown <git@davidb.org> writes:
> ...
> self - patch sender. Same as --suppress-from.
> author - patch author.
> cc - cc lines mentioned in the patch.
> cccmd - avoid running the cccmd.
> sob - signed off by lines.
> all - all non-explicit recipients
>
> Signed-off-by: David Brown <git@davidb.org>
> ...
> What bothers me most about this change is that --signed-of-cc
> and --suppress-from are silently ignored if --suppress-cc is given, either
> on the command line, or in the config.
The order in which various variables are set in the current code
before your patch is like this:
* my ($var) introduces them -- they are undefined at the
beginning;
* GetOptions() may set them to explicit values;
* read_config(), first for the specific sendemail identity and
then for the generic ones, fill the ones that are still
undefined;
* the built-in default from %config_bool_settings are used to
fill the ones that are still undefined at this point;
Now, I think you can build on top of the above by adding the
following after that sequence:
* fill %suppress_cc with explicit @suppress_cc GetOptions and
read_config() read;
* if the --suppress-from and/or --signed-off-by-cc, either from
GetOptions() or from read_config() are given, make them
override what @suppress_cc says. So giving --suppress-cc=all
and --signed-off-by-cc at the same time will still send cc to
people who signed off the patch (because these old-style ones
are more specific).
Perhaps something like this (untested, of course!) patch on top
of yours.
git-send-email.perl | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 1f03d12..cde5ffb 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -188,8 +188,8 @@ my (@suppress_cc);
my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
- "suppressfrom" => [\$suppress_from, 0],
- "signedoffcc" => [\$signed_off_cc, 1],
+ "suppressfrom" => [\$suppress_from, undef],
+ "signedoffcc" => [\$signed_off_cc, undef],
"smtpssl" => [\$smtp_ssl, 0],
);
@@ -279,18 +279,20 @@ if (@suppress_cc) {
unless $entry =~ /^(all|cccmd|cc|author|self|sob)$/;
$suppress_cc{$entry} = 1;
}
-} else {
- # Convert the old-style options.
- $suppress_cc{'self'} = 1 if $suppress_from;
- $suppress_cc{'sob'} = 1 unless $signed_off_cc;
}
-
if ($suppress_cc{'all'}) {
foreach my $entry (qw (ccmd cc author self sob)) {
$suppress_cc{$entry} = 1;
}
delete $suppress_cc{'all'};
}
+# If explicit old-style ones are specified, they trump supress-cc
+if (defined $suppress_from) {
+ $suppress_cc{'self'} = $suppress_from;
+}
+if (defined $signed_off_cc) {
+ $suppress_cc{'sob'} = !$signed_off_cc;
+}
my ($repoauthor) = $repo->ident_person('author');
my ($repocommitter) = $repo->ident_person('committer');
^ permalink raw reply related
* Re: [PATCH] Fix "git log --diff-filter" bug
From: Jakub Narebski @ 2007-12-25 22:44 UTC (permalink / raw)
To: Arjen Laarhoven; +Cc: gitster, git
In-Reply-To: <1198580807-18802-1-git-send-email-arjen@yaph.org>
Arjen Laarhoven <arjen@yaph.org> writes:
> In commit b7bb760d5ed4881422673d32f869d140221d3564 an optimization
> was made to avoid unnecessary diff generation. This was partly fixed
> in 99516e35d096f41e7133cacde8fbed8ee9a3ecd0, but obviously the
> '--diff-filter' option also needs the diff machinery in action.
Thanks a lot! I was wondering why 'git log --diff-filter=M' didn't
find anything...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: David Brown @ 2007-12-26 3:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Joel Becker
In-Reply-To: <7vk5n2o58p.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 25, 2007 at 01:04:54PM -0800, Junio C Hamano wrote:
>+# If explicit old-style ones are specified, they trump supress-cc
>+if (defined $suppress_from) {
>+ $suppress_cc{'self'} = $suppress_from;
>+}
>+if (defined $signed_off_cc) {
>+ $suppress_cc{'sob'} = !$signed_off_cc;
>+}
This changes the default behavior to --no-signed-off-cc, if nothing is
specified. I'll see if I can add something that will set that if no
suppress-cc's are set.
Patch to follow shortly.
David
^ permalink raw reply
* [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: David Brown @ 2007-12-26 3:56 UTC (permalink / raw)
To: git; +Cc: Joel Becker, Junio C Hamano
In-Reply-To: <7vk5n2o58p.fsf@gitster.siamese.dyndns.org>
There are a few options to git-send-email to suppress the automatic
generation of 'Cc' fields: --suppress-from, and --signed-off-cc.
However, there are other times that git-send-email automatically
includes Cc'd recipients. This is not desirable for all development
environments.
Add a new option --suppress-cc, which can be specified one or more
times to list the categories of auto-cc fields that should be
suppressed. If not specified, it defaults to values to give the same
behavior as specified by --suppress-from, and --signed-off-cc. The
categories are:
self - patch sender. Same as --suppress-from.
author - patch author.
cc - cc lines mentioned in the patch.
cccmd - avoid running the cccmd.
sob - signed off by lines.
all - all non-explicit recipients
Signed-off-by: David Brown <git@davidb.org>
---
I've now added changes similar to those suggested by Junio Hamano so
that signed-off-cc and suppress-from override values set by
signed-off-by.
Dave
Documentation/git-send-email.txt | 11 +++++++
git-send-email.perl | 56 +++++++++++++++++++++++++++++++++-----
2 files changed, 60 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index f0bd285..3dcea86 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -117,6 +117,17 @@ The --cc option must be repeated for each user you want on the cc list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
+--suppress-cc::
+ Specify an additional category of recipients to suppress the
+ auto-cc of. 'self' will avoid including the sender, 'author' will
+ avoid including the patch author, 'cc' will avoid including anyone
+ mentioned in Cc lines in the patch, 'sob' will avoid including
+ anyone mentioned in Signed-off-by lines, and 'cccmd' will avoid
+ running the --cc-cmd. 'all' will suppress all auto cc values.
+ Default is the value of 'sendemail.suppresscc' configuration value;
+ if that is unspecified, default to 'self' if --suppress-from is
+ specified, as well as 'sob' if --no-signed-off-cc is specified.
+
--thread, --no-thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
diff --git a/git-send-email.perl b/git-send-email.perl
index e47994a..a4cf4a9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -88,6 +88,12 @@ Options:
--smtp-ssl If set, connects to the SMTP server using SSL.
+ --suppress-cc Suppress the specified category of auto-CC. The category
+ can be one of 'author' for the patch author, 'self' to
+ avoid copying yourself, 'sob' for Signed-off-by lines,
+ 'cccmd' for the output of the cccmd, or 'all' to suppress
+ all of these.
+
--suppress-from Suppress sending emails to yourself. Defaults to off.
--thread Specify that the "In-Reply-To:" header should be set on all
@@ -177,12 +183,13 @@ my ($quiet, $dry_run) = (0, 0);
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
+my (@suppress_cc);
my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
- "suppressfrom" => [\$suppress_from, 0],
- "signedoffcc" => [\$signed_off_cc, 1],
+ "suppressfrom" => [\$suppress_from, undef],
+ "signedoffcc" => [\$signed_off_cc, undef],
"smtpssl" => [\$smtp_ssl, 0],
);
@@ -196,6 +203,7 @@ my %config_settings = (
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
"aliasesfile" => \@alias_files,
+ "suppresscc" => \@suppress_cc,
);
# Begin by accumulating all the variables (defined above), that we will end up
@@ -218,6 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"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_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
@@ -262,6 +271,35 @@ foreach my $setting (values %config_bool_settings) {
${$setting->[0]} = $setting->[1] unless (defined (${$setting->[0]}));
}
+# Set CC suppressions
+my(%suppress_cc);
+if (@suppress_cc) {
+ foreach my $entry (@suppress_cc) {
+ die "Unknown --suppress-cc field: '$entry'\n"
+ unless $entry =~ /^(all|cccmd|cc|author|self|sob)$/;
+ $suppress_cc{$entry} = 1;
+ }
+}
+
+if ($suppress_cc{'all'}) {
+ foreach my $entry (qw (ccmd cc author self sob)) {
+ $suppress_cc{$entry} = 1;
+ }
+ delete $suppress_cc{'all'};
+}
+
+# If explicit old-style ones are specified, they trump --suppress-cc.
+$suppress_cc{'self'} = $suppress_from if defined $suppress_from;
+$suppress_cc{'sob'} = $signed_off_cc if defined $signed_off_cc;
+
+# Debugging, print out the suppressions.
+if (0) {
+ print "suppressions:\n";
+ foreach my $entry (keys %suppress_cc) {
+ printf " %-5s -> $suppress_cc{$entry}\n", $entry;
+ }
+}
+
my ($repoauthor) = $repo->ident_person('author');
my ($repocommitter) = $repo->ident_person('committer');
@@ -701,11 +739,14 @@ foreach my $t (@files) {
} elsif (/^(Cc|From):\s+(.*)$/) {
if (unquote_rfc2047($2) eq $sender) {
- next if ($suppress_from);
+ next if ($suppress_cc{'self'});
}
elsif ($1 eq 'From') {
($author, $author_encoding)
= unquote_rfc2047($2);
+ next if ($suppress_cc{'author'});
+ } else {
+ next if ($suppress_cc{'cc'});
}
printf("(mbox) Adding cc: %s from line '%s'\n",
$2, $_) unless $quiet;
@@ -732,7 +773,7 @@ foreach my $t (@files) {
# line 2 = subject
# So let's support that, too.
$input_format = 'lots';
- if (@cc == 0) {
+ if (@cc == 0 && !$suppress_cc{'cc'}) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
$_, $_) unless $quiet;
@@ -749,10 +790,11 @@ foreach my $t (@files) {
}
} else {
$message .= $_;
- if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
+ if (/^(Signed-off-by|Cc): (.*)$/i) {
+ next if ($suppress_cc{'sob'});
my $c = $2;
chomp $c;
- next if ($c eq $sender and $suppress_from);
+ next if ($c eq $sender and $suppress_cc{'self'});
push @cc, $c;
printf("(sob) Adding cc: %s from line '%s'\n",
$c, $_) unless $quiet;
@@ -761,7 +803,7 @@ foreach my $t (@files) {
}
close F;
- if (defined $cc_cmd) {
+ if (defined $cc_cmd && !$suppress_cc{'cccmd'}) {
open(F, "$cc_cmd $t |")
or die "(cc-cmd) Could not execute '$cc_cmd'";
while(<F>) {
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] git-send-email: Generalize auto-cc recipient mechanism.
From: Sean @ 2007-12-26 4:54 UTC (permalink / raw)
To: David Brown; +Cc: git, Joel Becker, Junio C Hamano
In-Reply-To: <1198641389-959-1-git-send-email-git@davidb.org>
On Tue, 25 Dec 2007 19:56:29 -0800
David Brown <git@davidb.org> wrote:
> Add a new option --suppress-cc, which can be specified one or more
> times to list the categories of auto-cc fields that should be
> suppressed. If not specified, it defaults to values to give the same
> behavior as specified by --suppress-from, and --signed-off-cc. The
> categories are:
>
> self - patch sender. Same as --suppress-from.
> author - patch author.
> cc - cc lines mentioned in the patch.
> cccmd - avoid running the cccmd.
> sob - signed off by lines.
> all - all non-explicit recipients
>
Hi Dave,
It's great to see you're taking care of this issue, it's one that i've tripped over
a few times. If your patch is accepted as-is, i think it's an improvement.
But i wonder about the case where a user has "sendemail.suppresscc = all" in their
~/.gitconfig. For the occasion when they do want to cc the author of
a patch, what do they do? The above UI seems to lack a way to enable a cc option
that has been disabled by default.
Cheers,
Sean
^ 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