* [ANNOUNCE] qgit2.1rc1_win.exe
From: Marco Costalba @ 2007-12-24 9:13 UTC (permalink / raw)
To: msysGit, Git Mailing List
Here
http://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe
You can find an auto-extract zip file with a version of qgit built for
Windows (Vista).
Requires msysgit (http://code.google.com/p/msysgit/)
Is not a real installation, no registry or other Windows resources
touched, just decompress in a directory, read the README and have fun.
Marco
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-24 9:13 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <476F6F95.1030506@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> Junio C Hamano wrote:
>> Avi Kivity <avi@qumranet.com> writes:
>>
>>> Document git rev-list's --first-parent option. Documentation taken from
>>> git log.
>>> ...
>>> +--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.
>>> +
>>>
>>
>> I am afraid that this description is not sufficient. The
>> history given by --first-parent is useful only in a very limited
>> use case, and the user needs to be aware of it.
>
> I don't know which use case you are referring to...
Please read the commit log message you snarfed the description
again.
First-parent is useful only if you are the primary integrator
and do not fast-forward from other people. Only in that case,
you will see the overview of "the primary integration branch".
Otherwise you will observe the history viewed by whoever
happened to make a merge, which would switch every time you
cross the fast-forward boundary.
Making it sound as if it always will give a better overview is
misleading.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprwwsbey.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Avi Kivity <avi@qumranet.com> writes:
>
>
>> Junio C Hamano wrote:
>>
>>> Avi Kivity <avi@qumranet.com> writes:
>>>
>>>
>>>> Document git rev-list's --first-parent option. Documentation taken from
>>>> git log.
>>>> ...
>>>> +--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.
>>>> +
>>>>
>>>>
>>> I am afraid that this description is not sufficient. The
>>> history given by --first-parent is useful only in a very limited
>>> use case, and the user needs to be aware of it.
>>>
>> I don't know which use case you are referring to...
>>
>
> Please read the commit log message you snarfed the description
> again.
>
>
[I assume you mean 0053e902; I just copied the output of git log --help]
> First-parent is useful only if you are the primary integrator
> and do not fast-forward from other people. Only in that case,
> you will see the overview of "the primary integration branch".
> Otherwise you will observe the history viewed by whoever
> happened to make a merge, which would switch every time you
> cross the fast-forward boundary.
>
>
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, or from upstream submission branches (which are very
similar). So, for me --first-parent means "show me actual development,
not syncs with upstream or cleanup branches".
> Making it sound as if it always will give a better overview is
> misleading.
>
I'll try to come up with better wording and submit a new patch.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-24 9:58 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <476F7EA4.1030001@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> Junio C Hamano wrote:
>> Avi Kivity <avi@qumranet.com> writes:
>>
>>
>>> Junio C Hamano wrote:
>>>
>>>> Avi Kivity <avi@qumranet.com> writes:
>>>>
>>>>
>>>>> Document git rev-list's --first-parent option. Documentation taken from
>>>>> git log.
>> ...
> [I assume you mean 0053e902; I just copied the output of git log --help]
Ahh, sorry, I thought you did "log -S--first-parent".
> 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.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejdcs9cb.fsf@gitster.siamese.dyndns.org>
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.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-24 11:18 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20071222180244.GD23262@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]
Rework get_rev_name to return NULL rather than "undefined" when a reference
is undefined. If --undefined is passed (default) git-name-rev prints
"undefined" for the name, else it die()s.
Make git-describe use --no-undefined when calling git-name-rev so that
--contains behavior matches the standard git-describe one.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On sam, déc 22, 2007 at 06:02:44 +0000, Pierre Habouzit wrote:
> Like I said on IRC, I saw that git describe --contains has a bad
> behaviour:
>
> $ git describe --match='asd*' HEAD; echo $?
> fatal: cannot describe 'e272415ab7da3bde51af2ce95c88d7be3abfba28'
> 128
> $ git describe --contains HEAD; echo $?
> undefined
> 0
Okay here is a patch to have git-name-rev have a strict mode where
it rejects undefined's. With this patch:
$ git describe --contains HEAD
fatal: cannot describe 'e26a806b93f2f2f2354831ce0f943347a8ba7c3e'
This patch is minimal and looks safe for master to me. A better patch
would probably to have shared some logic between name-rev and
describe, but this would have been a quite larger patch, and I was
uncomfortable with it.
builtin-describe.c | 3 ++-
builtin-name-rev.c | 34 ++++++++++++++++++++++++----------
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 18eab47..3428483 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -271,10 +271,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
if (contains) {
- const char **args = xmalloc((5 + argc) * sizeof(char*));
+ const char **args = xmalloc((6 + argc) * sizeof(char*));
int i = 0;
args[i++] = "name-rev";
args[i++] = "--name-only";
+ args[i++] = "--no-undefined";
if (!all) {
args[i++] = "--tags";
if (pattern) {
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index a0c89a8..f22c8b5 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -125,18 +125,18 @@ static int name_ref(const char *path, const unsigned char *sha1, int flags, void
}
/* returns a static buffer */
-static const char* get_rev_name(struct object *o)
+static const char *get_rev_name(struct object *o)
{
static char buffer[1024];
struct rev_name *n;
struct commit *c;
if (o->type != OBJ_COMMIT)
- return "undefined";
+ return NULL;
c = (struct commit *) o;
n = c->util;
if (!n)
- return "undefined";
+ return NULL;
if (!n->generation)
return n->tip_name;
@@ -159,7 +159,7 @@ static char const * const name_rev_usage[] = {
int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = { 0, 0, NULL };
- int all = 0, transform_stdin = 0;
+ int all = 0, transform_stdin = 0, allow_undefined = 1;
struct name_ref_data data = { 0, 0, NULL };
struct option opts[] = {
OPT_BOOLEAN(0, "name-only", &data.name_only, "print only names (no SHA-1)"),
@@ -169,6 +169,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
OPT_GROUP(""),
OPT_BOOLEAN(0, "all", &all, "list all commits reachable from all refs"),
OPT_BOOLEAN(0, "stdin", &transform_stdin, "read from stdin"),
+ OPT_BOOLEAN(0, "undefined", &allow_undefined, "allow to print `undefined` names"),
OPT_END(),
};
@@ -226,7 +227,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
else if (++forty == 40 &&
!ishex(*(p+1))) {
unsigned char sha1[40];
- const char *name = "undefined";
+ const char *name = NULL;
char c = *(p+1);
forty = 0;
@@ -240,11 +241,10 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
}
*(p+1) = c;
- if (!strcmp(name, "undefined"))
+ if (!name)
continue;
- fwrite(p_start, p - p_start + 1, 1,
- stdout);
+ fwrite(p_start, p - p_start + 1, 1, stdout);
printf(" (%s)", name);
p_start = p + 1;
}
@@ -260,18 +260,32 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
max = get_max_object_index();
for (i = 0; i < max; i++) {
struct object * obj = get_indexed_object(i);
+ const char *name;
if (!obj)
continue;
if (!data.name_only)
printf("%s ", sha1_to_hex(obj->sha1));
- printf("%s\n", get_rev_name(obj));
+ name = get_rev_name(obj);
+ if (name)
+ printf("%s\n", name);
+ else if (allow_undefined)
+ printf("undefined\n");
+ else
+ die("cannot describe '%s'", sha1_to_hex(obj->sha1));
}
} else {
int i;
for (i = 0; i < revs.nr; i++) {
+ const char *name;
if (!data.name_only)
printf("%s ", revs.objects[i].name);
- printf("%s\n", get_rev_name(revs.objects[i].item));
+ name = get_rev_name(revs.objects[i].item);
+ if (name)
+ printf("%s\n", name);
+ else if (allow_undefined)
+ printf("undefined\n");
+ else
+ die("cannot describe '%s'", sha1_to_hex(revs.objects[i].item->sha1));
}
}
--
1.5.4.rc1.1123.ge26a8
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] cvsimport: die on cvsps errors
From: Miklos Vajna @ 2007-12-24 12:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Stefan Sperling
In-Reply-To: <20071224030819.GA15485@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
On Sun, Dec 23, 2007 at 10:08:19PM -0500, Jeff King <peff@peff.net> wrote:
> > That being said, it's awful that git-cvsimport doesn't stop when cvsps
> > exits with an error, producing all of those meaningless errors. Patch
> > will follow.
>
> And here it is.
great, thanks :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Miklos Vajna @ 2007-12-24 12:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik <jeff@garzik.org> wrote:
> Another year, another update! :)
>
> The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
one minor note:
i would suggest using:
$ git shortlog master..HEAD
instead of
$ git log master..HEAD | git shortlog
to avoid unnecessary complexity :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Robert P. J. Day @ 2007-12-24 14:19 UTC (permalink / raw)
To: Dieter Ries; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <476E5CFC.5070301@gmx.de>
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?
FYI, i'm typing in my own reference list as we speak here:
http://www.crashcourse.ca/wiki/index.php/Git
still quite a bit to go, but you can get the overall idea. new
sections should be appearing there as the morning progresses.
rday
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* [PATCH] Force new line at end of commit message
From: Bernt Hansen @ 2007-12-24 14:31 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <87ve6ub3u7.fsf@gollum.intra.norang.ca>
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.
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
---
This may well be the wrong fix for this problem but my attempts to make
git-rebase--interactive.sh append a newline breaks too many tests in the
test suite.
I tried something like this in git-rebase--interactive.sh:
- git cat-file commit HEAD | sed -e '1,/^$/d'
+ git cat-file commit HEAD | sed -e '1,/^$/d' -e '$a\'
Sorry I don't have an automated test for git-gui. Are there any?
git-gui/lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index b2d2d53..1c0586c 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -303,7 +303,7 @@ A rescan will be automatically started now.
puts stderr [mc "warning: Tcl does not support encoding '%s'." $enc]
fconfigure $msg_wt -encoding utf-8
}
- puts -nonewline $msg_wt $msg
+ puts $msg_wt $msg
close $msg_wt
# -- Create the commit.
--
1.5.4.rc1.22.g88b9
^ permalink raw reply related
* 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
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