* Re: Help with a tcl/tk gui thing..
From: Mikael Magnusson @ 2008-10-02 15:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810020746480.3341@nehalem.linux-foundation.org>
2008/10/2 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Thu, 2 Oct 2008, Mikael Magnusson wrote:
>>
>> Heh, sorry, I'm an idiot. I forgot to put '#!/usr/bin/python' on the first
>> line. I was running 'python tracker-ui.py' then did chmod +x just before
>> committing :). So the cross is coming from running 'import time'.
>
> Ahh. It did _something_, so I assumed it was working, just not well. Being
> confused about the language would do it ;)
>
> I fixed it up and merged it as an alternate UI. It doesn't react well to a
> tracker file that has just been initialized with the timeout (but without
> any of the extra information that gets filled out once you actually start
> getting tracked), but it's certainly prettier than my original one.
Ah, I didn't play around too much with the actual server part, but I guess
that would get sort of annoying, so I pushed a fix for that, and also it
now sets the window title right.
I should also note that I'm not exactly a python master, so if it looks ugly,
blame me, not python :).
--
Mikael Magnusson
^ permalink raw reply
* Re: How to remove a commit object?
From: Johannes Sixt @ 2008-10-02 15:02 UTC (permalink / raw)
To: Klas Lindberg
Cc: Jakub Narebski, Michael J Gruber, Steven Grimm, Git Users List
In-Reply-To: <33f4f4d70810020726g71c6f39eq16585269fb268322@mail.gmail.com>
Klas Lindberg schrieb:
> A solution to both problems seemed to be to use git-filter-branch to
> create a new repo by filtering out all the unwanted files. The
> astonishing result was that, for the subdirectory I tried it on, 90%
> or so of the commits on that subdirectory just disappeared. It didn't
> look right at all. Although I can't say for sure exactly what I did
> with filter-branch, I would appreciate some guidance for using it. It
> basically seemed to do exactly what I wanted (recreate the repo, minus
> some explicit stuff, with history intact otherwise), except the result
> looked crazy.
And your definition of 'crazy' is...?
I assume that you used --subdirectory-filter. This has issues that will be
fixed in 1.6.1. You need a current 'master' git (at least b805ef08).
-- Hannes
^ permalink raw reply
* Re: [PATCH (BUGFIX)] gitweb: Fix two 'uninitialized value' varnings in git_tree()
From: Giuseppe Bilotta @ 2008-10-02 15:02 UTC (permalink / raw)
To: git
In-Reply-To: <20081002144602.19247.4434.stgit@localhost.localdomain>
On Thursday 02 October 2008 16:50, Jakub Narebski wrote:
> gitweb: Fix two 'uninitialized value' varnings in git_tree()
Vat's a varning?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] gitweb: Add path_info tests to t/t9500-gitweb-standalone-no-errors.sh
From: Petr Baudis @ 2008-10-02 15:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20081002145010.19247.44420.stgit@localhost.localdomain>
On Thu, Oct 02, 2008 at 04:52:20PM +0200, Jakub Narebski wrote:
> Note that those tests only that there are no errors nor warnings
> from Perl; they do not check for example if gitweb doesn't use
> ARRAY(0x8e3cc20) instead of correct value in links, etc.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This is the test thans to which I have dicovered errors in git_tree()
> fixed in previous email. Nevertheless those two patches are unrelated,
> so they are not numbered.
>
> Those tests check _current_ situation, without $action, not
> $hash_parent parameters possible in path_info.
I didn't test the patch but it all looks sensible.
Acked-by: Petr Baudis <pasky@suse.cz>
^ permalink raw reply
* Re: [PATCH] git-cvsexportcommit: handle file status reported out of order (was Re: [PATCH] Make git-cvsexportcommit "status" each file in turn)
From: Nick Woolley @ 2008-10-02 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810021428170.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin wrote:
> Please research a bit better. If the basenames are not unique, several
> cvs status calls are used. See commit
> fef3a7cc5593d3951a5f95c92986fb9982c2cc86.
Yes, I see. I did spend some time searching for prior art on this issue,
but I obviously wasn't looking in the right places.
> I can only assume that you have not really hung out on this list for very
> long; this is no way near the way patches are expected here.
Correct.
> Also, given the fact that you actually verified that it was fixed in
> 1.6.0, what exactly is your proposed course of action? Revert the fix in
> 1.6.0 and apply your patch? Apply your patch to 1.5.6.5, cracking a
> release 1.5.6.6 with your patch?
Neither. At the moment, I can only offer what I have: a patch for
1.5.6.5, representing an idea that may contribute something small to
1.6.0 (using information from CVS on STDERR). It should be simple to
adapt if it's useful, if not please ignore it.
By posting, I hoped to learn if it was useful and where to look for the
information I was missing, which you've been helpful enough to point out.
Thanks,
N
^ permalink raw reply
* Re: [PATCH (BUGFIX)] gitweb: Fix two 'uninitialized value' varnings in git_tree()
From: Petr Baudis @ 2008-10-02 15:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20081002144602.19247.4434.stgit@localhost.localdomain>
On Thu, Oct 02, 2008 at 04:50:04PM +0200, Jakub Narebski wrote:
> If we did try to access nonexistent directory or file, which means
> that git_get_hash_by_path() returns `undef`, uninitialized $hash
> variable was passed to 'open' call. Now we fail early with "404 Not
> Found - No such tree" error. (If we try to access something which
> does not resolve to tree-ish, for example a file / 'blob' object, the
> error will be caught later, as "404 Not Found - Reading tree failed"
> error).
>
> If we tried to use 'tree' action without $file_name ('f' parameter)
> set, which means either tree given by hash or a top tree (and we
> currently cannot distinguish between those two cases), we cannot print
> path breadcrumbs with git_print_page_path(). Fix this by moving call
> to git_print_page_path() inside conditional.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
> BTW. should we use "No such tree" or "No such directory".
I prefer the former.
^ permalink raw reply
* [PATCH] gitweb: Support for tag clouds
From: Petr Baudis @ 2008-10-02 15:13 UTC (permalink / raw)
To: git, git; +Cc: Petr Baudis
In-Reply-To: <"<1222957505-5150-1-git-send-email-pasky@suse.cz>
The "Content tags" (nothing to do with usual Git tags!) are free-form
strings that are attached to random projects and displayed in the
well-known Web2.0-ish tag cloud above project list.
The feature will make use of HTML::TagCloud if available, but will
still display (less pretty) list of tags in case the module is not
installed.
The tagging itself is not done by gitweb - user-provided external
helper CGI needs to be provided; one example is the tagproj.cgi
of Girocco. This functionality might get integrated to gitweb
in the future.
The tags are stored one-per-file in ctags/ subdirectory. The reason
they are not stored in the project config file is that you usually
want to give anyone (even CGI scripts) permission to create new tags
and they are non-essential information, and thus you would make
the ctags/ subdirectory world-writable.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
---
gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bd8124a..5ba094e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -275,6 +275,24 @@ our %feature = (
'forks' => {
'override' => 0,
'default' => [0]},
+
+ # Allow gitweb scan project content tags described in ctags/
+ # of project repository, and display the popular Web 2.0-ish
+ # "tag cloud" near the project list. Note that this is something
+ # COMPLETELY different from the normal Git tags.
+
+ # gitweb by itself can show existing tags, but it does not handle
+ # tagging itself; you need an external application for that.
+ # For an example script, check Girocco's cgi/tagproj.cgi.
+ # You may want to install the HTML::TagCloud Perl module to get
+ # a pretty tag cloud instead of just a list of tags.
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'ctags'}{'default'} = ['path_to_tag_script'];
+ # Project specific override is not supported.
+ 'ctags' => {
+ 'override' => 0,
+ 'default' => [0]},
);
sub gitweb_check_feature {
@@ -1755,6 +1773,67 @@ sub git_get_project_description {
return $descr;
}
+sub git_get_project_ctags {
+ my $path = shift;
+ my $ctags = {};
+
+ $git_dir = "$projectroot/$path";
+ foreach (<$git_dir/ctags/*>) {
+ open CT, $_ or next;
+ my $val = <CT>;
+ chomp $val;
+ close CT;
+ my $ctag = $_; $ctag =~ s#.*/##;
+ $ctags->{$ctag} = $val;
+ }
+ $ctags;
+}
+
+sub git_populate_project_tagcloud {
+ my $ctags = shift;
+
+ # First, merge different-cased tags; tags vote on casing
+ my %ctags_lc;
+ foreach (keys %$ctags) {
+ $ctags_lc{lc $_}->{count} += $ctags->{$_};
+ if (not $ctags_lc{lc $_}->{topcount}
+ or $ctags_lc{lc $_}->{topcount} < $ctags->{$_}) {
+ $ctags_lc{lc $_}->{topcount} = $ctags->{$_};
+ $ctags_lc{lc $_}->{topname} = $_;
+ }
+ }
+
+ my $cloud;
+ if (eval { require HTML::TagCloud; 1; }) {
+ $cloud = HTML::TagCloud->new;
+ foreach (sort keys %ctags_lc) {
+ # Pad the title with spaces so that the cloud looks
+ # less crammed.
+ my $title = $ctags_lc{$_}->{topname};
+ $title =~ s/ / /g;
+ $title =~ s/^/ /g;
+ $title =~ s/$/ /g;
+ $cloud->add($title, $home_link."?by_tag=".$_, $ctags_lc{$_}->{count});
+ }
+ } else {
+ $cloud = \%ctags_lc;
+ }
+ $cloud;
+}
+
+sub git_show_project_tagcloud {
+ my ($cloud, $count) = @_;
+ print STDERR ref($cloud)."..\n";
+ if (ref $cloud eq 'HTML::TagCloud') {
+ return $cloud->html_and_css($count);
+ } else {
+ my @tags = sort { $cloud->{$a}->{count} <=> $cloud->{$b}->{count} } keys %$cloud;
+ return '<p align="center">' . join (', ', map {
+ "<a href=\"$home_link?by_tag=$_\">$cloud->{$_}->{topname}</a>"
+ } splice(@tags, 0, $count)) . '</p>';
+ }
+}
+
sub git_get_project_url_list {
my $path = shift;
@@ -3573,6 +3652,7 @@ sub fill_project_list_info {
my ($projlist, $check_forks) = @_;
my @projects;
+ my $show_ctags = gitweb_check_feature('ctags');
PROJECT:
foreach my $pr (@$projlist) {
my (@activity) = git_get_last_activity($pr->{'path'});
@@ -3599,6 +3679,7 @@ sub fill_project_list_info {
$pr->{'forks'} = 0;
}
}
+ $show_ctags and $pr->{'ctags'} = git_get_project_ctags($pr->{'path'});
push @projects, $pr;
}
@@ -3645,6 +3726,18 @@ sub git_project_list_body {
$from = 0 unless defined $from;
$to = $#projects if (!defined $to || $#projects < $to);
+ my $show_ctags = gitweb_check_feature('ctags');
+ if ($show_ctags) {
+ my %ctags;
+ foreach my $p (@projects) {
+ foreach my $ct (keys %{$p->{'ctags'}}) {
+ $ctags{$ct} += $p->{'ctags'}->{$ct};
+ }
+ }
+ my $cloud = git_populate_project_tagcloud(\%ctags);
+ print git_show_project_tagcloud($cloud, 64);
+ }
+
print "<table class=\"project_list\">\n";
unless ($no_header) {
print "<tr>\n";
@@ -3663,8 +3756,10 @@ sub git_project_list_body {
"</tr>\n";
}
my $alternate = 1;
+ my $tagfilter = $cgi->param('by_tag');
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
+ next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
@@ -4086,6 +4181,20 @@ sub git_summary {
print "<tr class=\"metadata_url\"><td>$url_tag</td><td>$git_url</td></tr>\n";
$url_tag = "";
}
+
+ # Tag cloud
+ my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ if ($show_ctags) {
+ my $ctags = git_get_project_ctags($project);
+ my $cloud = git_populate_project_tagcloud($ctags);
+ print "<tr id=\"metadata_ctags\"><td>Content tags:<br />";
+ print "</td>\n<td>" unless %$ctags;
+ print "<form action=\"$show_ctags\" method=\"post\"><input type=\"hidden\" name=\"p\" value=\"$project\" />Add: <input type=\"text\" name=\"t\" size=\"8\" /></form>";
+ print "</td>\n<td>" if %$ctags;
+ print git_show_project_tagcloud($cloud, 48);
+ print "</td></tr>";
+ }
+
print "</table>\n";
if (-s "$projectroot/$project/README.html") {
--
tg: (c5a1246..) t/tagcloud/tagcloud (depends on: vanilla/master t/summary/css-metadata)
^ permalink raw reply related
* [PATCH] gitweb: Make the by_tag filter delve in forks as well
From: Petr Baudis @ 2008-10-02 15:17 UTC (permalink / raw)
To: git, git; +Cc: Petr Baudis
In-Reply-To: <1222960382-11619-1-git-send-email-pasky@suse.cz>
This requires us to build a full index including forks and then weed
them out only when printing.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
---
gitweb/gitweb.perl | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 02083d5..07fa1e6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1880,9 +1880,7 @@ sub git_get_projects_list {
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
- if ($check_forks and $subdir =~ m#/.#) {
- $File::Find::prune = 1;
- } elsif (check_export_ok("$projectroot/$filter/$subdir")) {
+ if (check_export_ok("$projectroot/$filter/$subdir")) {
push @list, { path => ($filter ? "$filter/" : '') . $subdir };
$File::Find::prune = 1;
}
@@ -3715,6 +3713,7 @@ sub print_sort_th_num {
}
sub git_project_list_body {
+ # actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
my ($check_forks) = gitweb_check_feature('forks');
@@ -3757,7 +3756,15 @@ sub git_project_list_body {
my $tagfilter = $cgi->param('by_tag');
for (my $i = $from; $i <= $to; $i++) {
my $pr = $projects[$i];
+
next if $tagfilter and $show_ctags and not grep { lc $_ eq lc $tagfilter } keys %{$pr->{'ctags'}};
+ # Weed out forks
+ if ($check_forks) {
+ my $forkbase = $project; $forkbase ||= ''; $forkbase =~ s#\.git$#/#;
+ $forkbase="^$forkbase" if $forkbase;
+ next if not $tagfilter and $pr->{'path'} =~ m#$forkbase.*/.*#; # regexp-safe
+ }
+
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
--
tg: (f429121..) t/tagcloud/forks (depends on: t/tagcloud/tagcloud)
^ permalink raw reply related
* Re: [PATCH] Solaris: Use OLD_ICONV to avoid compile warnings
From: Brandon Casey @ 2008-10-02 15:25 UTC (permalink / raw)
To: Jeff King; +Cc: David Soria Parra, git, David Soria Parra
In-Reply-To: <20081002010816.GA27415@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Oct 02, 2008 at 02:08:47AM +0200, David Soria Parra wrote:
>
>> Solaris systems use the old styled iconv(3) call and therefore
>> the OLD_ICONV variable should be set. Otherwise we get annoying compile
>> warnings.
>
> Acked-by: Jeff King <peff@peff.net>
>
> I set OLD_ICONV on my Solaris build.
Ditto here on 7.
>
> Do you also unset NEEDS_LIBICONV (and which version of Solaris are you
> running)?
I do not set NEEDS_LIBICONV.
-brandon
^ permalink raw reply
* Re: Git commit hash clash prevention
From: Johannes Schindelin @ 2008-10-02 15:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: martin f krafft, git discussion list
In-Reply-To: <m3prmjqeq8.fsf@localhost.localdomain>
Hi,
On Thu, 2 Oct 2008, Jakub Narebski wrote:
> martin f krafft <madduck@madduck.net> writes:
>
> > the other day during a workshop on Git, one of the attendants asked
> > about the scenario when two developers, Jane and David, both working
> > on the same project, both create a commit and the two just so happen
> > to have the same SHA-1. I realise that the likelihood of this
> > happening is about as high as the chance of <insert witty joke
> > here>, but it *is* possible, isn't it? Even though this is thus
> > somewhat academic, I am still very curious about it.
> >
> > What happens when David now pulls from Jane? How does Git deal with
> > this?
>
> Cannot happen in practice.
>
> But just in case git trusts object it already has in repository over
> object which just got fetched (or pushed).
Oh, maybe the most important part: both David and Jane would have to
rewrite their respective history, changing the respective commits in a
simple way (such as adding a space to the first line of the commit message
or some such). Then, Git is changed to not accept that particular SHA-1
(we'd introduce a black "list").
All in all, it would be like a borked commit; not really easy to fix, but
the world would not stop turning because of it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Petr Baudis @ 2008-10-02 15:34 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <1222906234-8182-2-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, Oct 02, 2008 at 02:10:29AM +0200, Giuseppe Bilotta wrote:
> This patch enables gitweb to parse URLs with more information embedded
> in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
> path is now $project/$action/$hash_base:$file_name or
> $project/$action/$hash
>
> This is mostly backwards compatible with the old-style gitweb paths,
> except when $project/$branch was used to access a branch whose name
> matches a gitweb action.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Just nits...
> ---
> gitweb/gitweb.perl | 90 +++++++++++++++++++++++++++++++---------------------
> 1 files changed, 54 insertions(+), 36 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e7e4d6b..f088681 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -519,9 +550,19 @@ sub evaluate_path_info {
> # do not change any parameters if an action is given using the query string
> return if $action;
> $path_info =~ s,^\Q$project\E/*,,;
> +
> + # next comes the action
> + $action = $path_info;
> + $action =~ s,/.*$,,;
> + if (exists $actions{$action}) {
> + $path_info =~ s,^$action/*,,;
> + } else {
> + $action = undef;
Extra whitespace.
> + }
> +
> my ($refname, $pathname) = split(/:/, $path_info, 2);
> if (defined $pathname) {
> - # we got "project.git/branch:filename" or "project.git/branch:dir/"
> + # we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
> $pathname =~ s,^/+,,;
> if (!$pathname || substr($pathname, -1) eq "/") {
But the old variant is still possible, maybe the comments should
indicate that the action/ part is optional.
> @@ -534,8 +575,9 @@ sub evaluate_path_info {
> $file_name ||= validate_pathname($pathname);
> } elsif (defined $refname) {
> # we got "project.git/branch"
> - $action ||= "shortlog";
> - $hash ||= validate_refname($refname);
> + $action ||= "shortlog";
> + $hash ||= validate_refname($refname);
> + $hash_base ||= validate_refname($refname);
> }
> }
> evaluate_path_info();
What is this good for?
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: Git commit hash clash prevention
From: Stephan Beyer @ 2008-10-02 16:04 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20081002085358.GA5342@lapse.rw.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
Hi,
martin f krafft wrote:
> Hi folks,
>
> the other day during a workshop on Git, one of the attendants asked
> about the scenario when two developers, Jane and David, both working
> on the same project, both create a commit and the two just so happen
> to have the same SHA-1.
Changing the committer time is the easiest way to solve this problem,
if it ever happens.
I have wondered how Git would behave if there are two files that are
not equal but have the same SHA-1. But I haven't found any such example
files to test this scenario and have not had the time to write or
look for a tool that generates them. (MD5 collisions can be generated
within 2 hours on usual home hardware and even Wikipedia links to
collided files. An intelligent search for SHA-1 collisions takes
2^63 evaluations and not 2^80 (simple birthday attack) as expected.
So it should be possible to find some random collisions and test the
behavior...)
But even if git behaves terrible useless in such situations, it
does not make any sense to guard against them, because in practice
they just do not happen. (And I think such guards will just slow git
down in the usual case.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: Add path_info tests to t/t9500-gitweb-standalone-no-errors.sh
From: Eric Raible @ 2008-10-02 16:41 UTC (permalink / raw)
To: git
In-Reply-To: <20081002145010.19247.44420.stgit@localhost.localdomain>
Jakub Narebski <jnareb <at> gmail.com> writes:
>
> Note that those tests only that there are no errors nor warnings
> from Perl; they do not check for example if gitweb doesn't use
> ARRAY(0x8e3cc20) instead of correct value in links, etc.
>
> Signed-off-by: Jakub Narebski <jnareb <at> gmail.com>
> ---
s/only that/only check that/
^ permalink raw reply
* Re: [PATCH] git-cvsexportcommit: handle file status reported out of order (was Re: [PATCH] Make git-cvsexportcommit "status" each file in turn)
From: Johannes Schindelin @ 2008-10-02 17:04 UTC (permalink / raw)
To: Nick Woolley; +Cc: git
In-Reply-To: <48E4E3F2.4000401@yahoo.co.uk>
Hi,
On Thu, 2 Oct 2008, Nick Woolley wrote:
> Johannes Schindelin wrote:
>
> > Also, given the fact that you actually verified that it was fixed in
> > 1.6.0, what exactly is your proposed course of action? Revert the fix
> > in 1.6.0 and apply your patch? Apply your patch to 1.5.6.5, cracking
> > a release 1.5.6.6 with your patch?
>
> Neither. At the moment, I can only offer what I have: a patch for
> 1.5.6.5, representing an idea that may contribute something small to
> 1.6.0 (using information from CVS on STDERR). It should be simple to
> adapt if it's useful, if not please ignore it.
Since you did not use the preferred form of a patch, you also do not have
a commit message describing the idea of your patch. It is a bit hard to
find out the intention from reading the source, and I am not motivated
enough to find out, given that it is fixed with the commit I referred you
to.
To save you time: the idea of the commit I referred you to is not exactly
to use the basename, but the trimmed names. Now only sets of unique names
(where it is also checked that a name could not be mistaken for another,
deleted file) are passed to cvs status.
BTW next time you search for some fix in Git's source code, you might want
to use either "git log -- <file>" or "git bisect" to find the commit in
question.
Hth,
Dscho
^ permalink raw reply
* [PATCH] format-patch: autonumber by default
From: Giuseppe Bilotta @ 2008-10-02 17:58 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Shawn O. Pearce,
Andreas Ericsson, Giuseppe Bilotta
In-Reply-To: <48E4D73B.9090508@op5.se>
format-patch is often used for multiple patches at once when sending a
patchset, in which case we want to number the patches; on the other
hand, single-patches are not usually expected to be numbered.
The typical behavior expected by format-patch is therefore the one
obtained by enabling autonumber, which should thus be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. For users that want to
change the default behavior we provide a 'noauto' option for the
format.numbering config key.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
builtin-log.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..5187dc2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -484,6 +484,10 @@ static int git_format_config(const char *var, const char *value, void *cb)
auto_number = 1;
return 0;
}
+ if (value && !strcasecmp(value, "noauto")) {
+ auto_number = 0;
+ return 0;
+ }
numbered = git_config_bool(var, value);
return 0;
}
--
1.5.6.5
^ permalink raw reply related
* Re: corrupted repository?
From: Francois Pepin @ 2008-10-02 18:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081002142952.GP21310@spearce.org>
> Your git-upload-pack cannot find git-pack-objects. It sounds like
> Git was incorrectly installed on your system.
You are correct. I had created some symlinks for the binaries because
the changes for the environment variable didn't see to work for me,
either from the installer package or editing the
~/.MacOSX/environment.plist. I had a link to git-upload-pack in /usr/bin
but none to git, thereby creating the issue.
I'm a bit confused as to how it happened, but's all been fixed and I'm a
happy camper again.
Thanks for the help,
Francois
^ permalink raw reply
* git apply: git diff header lacks filename information for git diff --no-index patch
From: Imre Deak @ 2008-10-02 18:27 UTC (permalink / raw)
To: git
Hi,
I have the following problem:
$ echo -e '\x0' > a
$ git diff --no-index --binary /dev/null a > patch
$ rm a
$ git apply patch
fatal: git diff header lacks filename information (line 4)
$ cat patch
diff --git a/dev/null b/a
new file mode 100644
index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
GIT binary patch
literal 2
JcmZSJ0ssIE01E&B
literal 0
HcmV?d00001
The same works for text based patches:
$ echo 1 > a
$ git diff --no-index /dev/null a > patch
$ rm a
$ git apply patch
$ ls
a
$ cat patch
diff --git a/dev/null b/a
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/a
@@ -0,0 +1 @@
+1
The binary patch lacks ---/+++ lines but still provides the name info
on the diff --git line which I think should suffice for git apply.
--Imre
^ permalink raw reply related
* Re: [PATCHv4] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-02 19:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Jakub Narebski, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <20081002153403.GQ10360@machine.or.cz>
On Thu, Oct 2, 2008 at 5:34 PM, Petr Baudis <pasky@suse.cz> wrote:
> Just nits...
>> + $action = undef;
>
> Extra whitespace.
Right, fixed.
>> + }
>> +
>> my ($refname, $pathname) = split(/:/, $path_info, 2);
>> if (defined $pathname) {
>> - # we got "project.git/branch:filename" or "project.git/branch:dir/"
>> + # we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
>> # we could use git_get_type(branch:pathname), but it needs $git_dir
>> $pathname =~ s,^/+,,;
>> if (!$pathname || substr($pathname, -1) eq "/") {
>
> But the old variant is still possible, maybe the comments should
> indicate that the action/ part is optional.
I put the action/ part in square brackets. (e.g.
project.git/[action/]branch:filename). Is this good enough?
>> @@ -534,8 +575,9 @@ sub evaluate_path_info {
>> $file_name ||= validate_pathname($pathname);
>> } elsif (defined $refname) {
>> # we got "project.git/branch"
>> - $action ||= "shortlog";
>> - $hash ||= validate_refname($refname);
>> + $action ||= "shortlog";
>> + $hash ||= validate_refname($refname);
>> + $hash_base ||= validate_refname($refname);
>> }
>> }
>> evaluate_path_info();
>
> What is this good for?
The purpose of what? setting both $hash and $hash_base was something
that I found was needed in some extreme cases, as discussed with
Jakub. Proposals for recommended cleaner but equally fast way to
handle it. If you're referring to the whitespace, I was just lining up
the entries. Should I do it in a separate patch?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] format-patch: autonumber by default
From: Jeff King @ 2008-10-02 20:03 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: git, Jakub Narebski, Johannes Schindelin, Shawn O. Pearce,
Andreas Ericsson
In-Reply-To: <1222970291-5337-1-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, Oct 02, 2008 at 07:58:11PM +0200, Giuseppe Bilotta wrote:
> format-patch is often used for multiple patches at once when sending a
> patchset, in which case we want to number the patches; on the other
> hand, single-patches are not usually expected to be numbered.
>
> The typical behavior expected by format-patch is therefore the one
> obtained by enabling autonumber, which should thus be the default.
I personally do not agree with this default. My usual use of
format-patch is to dump a cluster of miscellaneous patches since
"origin", and then grab the one(s) I want by title.
However, I would not be surprised to find that my use is unlike that of
most other people[1], so I am not opposed to the patch.
[1] Actually, my use has a deficiency, which is that I am often sending
2/4, without nobody having seen 1/4, on which it might actually depend.
This works in practice for me because I am often producing unrelated
janitorial patches for git. :)
So I think the goal is reasonable, but:
> ---
> builtin-log.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
Documentation update?
-Peff
^ permalink raw reply
* [PATCH] format-patch: autonumber by default
From: Giuseppe Bilotta @ 2008-10-02 20:15 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Shawn O. Pearce, Jeff King,
Giuseppe Bilotta
In-Reply-To: <20081002200333.GA29303@coredump.intra.peff.net>
format-patch is most commoly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on the
other hand, single patches are not usually expected to be numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do so
with the existing -N command-line switch. For users that want to change
the default behavior we provide a 'noauto' option for the
format.numbering config key.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Documentation/config.txt | 5 +++--
Documentation/git-format-patch.txt | 9 ++++++---
builtin-log.c | 6 +++++-
3 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bbe38cc..9a9ed98 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -633,8 +633,9 @@ fetch.unpackLimit::
format.numbered::
A boolean which can enable sequence numbers in patch subjects.
Setting this option to "auto" will enable it only if there is
- more than one patch. See --numbered option in
- linkgit:git-format-patch[1].
+ more than one patch. This is the default behavior and can be
+ disabled by setting this option to "noauto". See --numbered
+ option in linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..d7be5bb 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -59,7 +59,9 @@ If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
+is formatted as "[PATCH n/m] Subject". This is the default behavior
+when outputting more than one patch, and it can be suppressed with
+the -N command line option.
If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
@@ -171,14 +173,15 @@ CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message
in the repository configuration, new defaults for the subject prefix
-and file suffix, and number patches when outputting more than one.
+and file suffix, and disable automatic numbering of patches when outputting
+more than one.
------------
[format]
headers = "Organization: git-foo\n"
subjectprefix = CHANGE
suffix = .txt
- numbered = auto
+ numbered = noauto
cc = <email>
------------
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..5187dc2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -484,6 +484,10 @@ static int git_format_config(const char *var, const char *value, void *cb)
auto_number = 1;
return 0;
}
+ if (value && !strcasecmp(value, "noauto")) {
+ auto_number = 0;
+ return 0;
+ }
numbered = git_config_bool(var, value);
return 0;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] format-patch: autonumber by default
From: Brian Gernhardt @ 2008-10-02 20:17 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: git, Jakub Narebski, Johannes Schindelin, Shawn O. Pearce,
Andreas Ericsson
In-Reply-To: <1222970291-5337-1-git-send-email-giuseppe.bilotta@gmail.com>
On Oct 2, 2008, at 1:58 PM, Giuseppe Bilotta wrote:
> diff --git a/builtin-log.c b/builtin-log.c
> index fc5e4da..5187dc2 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -426,7 +426,7 @@ static int istitlechar(char c)
>
> static const char *fmt_patch_suffix = ".patch";
> static int numbered = 0;
> -static int auto_number = 0;
> +static int auto_number = 1;
>
> static char **extra_hdr;
> static int extra_hdr_nr;
> @@ -484,6 +484,10 @@ static int git_format_config(const char *var,
> const char *value, void *cb)
> auto_number = 1;
> return 0;
> }
> + if (value && !strcasecmp(value, "noauto")) {
> + auto_number = 0;
> + return 0;
> + }
> numbered = git_config_bool(var, value);
> return 0;
> }
format.numbered is a tri-state config option right now: {yes, no,
auto}. With this patch, if you add "[format] numbered = false" into
your config, you still get auto-numbering.
A better way to do this might be to default both numbered and
auto_number to true and only use auto_number is numbered is true. Or
turn off auto-numbering when numbering is turned off just below your
hunk.
Either way, "noauto" is a bad idea. It's spelled "no" or "false".
~~ Brian Gernhardt
^ permalink raw reply
* [PATCH] format-patch: autonumber by default
From: Brian Gernhardt @ 2008-10-02 20:36 UTC (permalink / raw)
To: Git List; +Cc: Shawn O Pearce
In-Reply-To: <91634D16-B28A-4458-97A9-C469B5AF4E5D@silverinsanity.com>
format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. Users that want to
change the default behavior can use the format.numbering config key.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
This is what I was talking about. The appropriate setting to turn it off is
"false", not "noauto".
Documentation/config.txt | 9 +++++----
Documentation/git-format-patch.txt | 8 +++++---
builtin-log.c | 3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..5ba3ffa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -640,10 +640,11 @@ fetch.unpackLimit::
`transfer.unpackLimit` is used instead.
format.numbered::
- A boolean which can enable sequence numbers in patch subjects.
- Setting this option to "auto" will enable it only if there is
- more than one patch. See --numbered option in
- linkgit:git-format-patch[1].
+ A boolean which can enable or disable sequence numbers in patch
+ subjects. It defaults to "auto" which enables it only if there
+ is more than one patch. It can be enabled or disabled for all
+ messages by setting it to "true" or "false". See --numbered
+ option in linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..ac36ce8 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -58,8 +58,10 @@ output, unless the --stdout option is specified.
If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
-If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
+By default, the subject of a single patch is "[PATCH] First Line" and
+the subject when multiple patches are output is "[PATCH n/m] First
+Line". To force 1/1 to be added for a single patch, use -n. To omit
+patch numbers from the subject, use -N
If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
@@ -81,7 +83,7 @@ include::diff-options.txt[]
-n::
--numbered::
- Name output in '[PATCH n/m]' format.
+ Name output in '[PATCH n/m]' format, even with a single patch.
-N::
--no-numbered::
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..93987ee 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -485,6 +485,7 @@ static int git_format_config(const char *var, const char *value, void *cb)
return 0;
}
numbered = git_config_bool(var, value);
+ auto_number &&= numbered;
return 0;
}
--
1.6.0.2.589.gcd70
^ permalink raw reply related
* [PATCH] format-patch: autonumber by default
From: Brian Gernhardt @ 2008-10-02 20:41 UTC (permalink / raw)
To: Git List
Cc: Giuseppe Bilotta, Jakub Narebski, Johannes Schindelin,
Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <91634D16-B28A-4458-97A9-C469B5AF4E5D@silverinsanity.com>
format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. Users that want to
change the default behavior can use the format.numbering config key.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
This is what I was talking about. The appropriate setting to turn it off is
"false", not "noauto".
Re-sending with the correct CC list.
Documentation/config.txt | 9 +++++----
Documentation/git-format-patch.txt | 8 +++++---
builtin-log.c | 3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..5ba3ffa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -640,10 +640,11 @@ fetch.unpackLimit::
`transfer.unpackLimit` is used instead.
format.numbered::
- A boolean which can enable sequence numbers in patch subjects.
- Setting this option to "auto" will enable it only if there is
- more than one patch. See --numbered option in
- linkgit:git-format-patch[1].
+ A boolean which can enable or disable sequence numbers in patch
+ subjects. It defaults to "auto" which enables it only if there
+ is more than one patch. It can be enabled or disabled for all
+ messages by setting it to "true" or "false". See --numbered
+ option in linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..ac36ce8 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -58,8 +58,10 @@ output, unless the --stdout option is specified.
If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
-If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
+By default, the subject of a single patch is "[PATCH] First Line" and
+the subject when multiple patches are output is "[PATCH n/m] First
+Line". To force 1/1 to be added for a single patch, use -n. To omit
+patch numbers from the subject, use -N
If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
@@ -81,7 +83,7 @@ include::diff-options.txt[]
-n::
--numbered::
- Name output in '[PATCH n/m]' format.
+ Name output in '[PATCH n/m]' format, even with a single patch.
-N::
--no-numbered::
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..93987ee 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -485,6 +485,7 @@ static int git_format_config(const char *var, const char *value, void *cb)
return 0;
}
numbered = git_config_bool(var, value);
+ auto_number &&= numbered;
return 0;
}
--
1.6.0.2.589.gcd70
^ permalink raw reply related
* Re: [PATCH] format-patch: autonumber by default
From: Brian Gernhardt @ 2008-10-02 20:50 UTC (permalink / raw)
To: Brian Gernhardt
Cc: Git List, Giuseppe Bilotta, Jakub Narebski, Johannes Schindelin,
Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <20081002204145.GA98400@Hermes>
Okay, I should wait for my test build to finish before I send the
patch. This doesn't build. Nor does it pass the tests, since they
test the old behavior.
I'll fix the build error, but I'm not inclined to spend the time
fixing the tests since I don't actually care about changing the default.
On Oct 2, 2008, at 4:41 PM, Brian Gernhardt wrote:
>
> format-patch is most commonly used for multiple patches at once when
> sending a patchset, in which case we want to number the patches; on
> the other hand, single patches are not usually expected to be
> numbered.
>
> In other words, the typical behavior expected from format-patch is the
> one obtained by enabling autonumber, so we set it to be the default.
>
> Users that want to disable numbering for a particular patchset can do
> so with the existing -N command-line switch. Users that want to
> change the default behavior can use the format.numbering config key.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
>
> This is what I was talking about. The appropriate setting to turn
> it off is
> "false", not "noauto".
>
> Re-sending with the correct CC list.
>
> Documentation/config.txt | 9 +++++----
> Documentation/git-format-patch.txt | 8 +++++---
> builtin-log.c | 3 ++-
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index da18a54..5ba3ffa 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -640,10 +640,11 @@ fetch.unpackLimit::
> `transfer.unpackLimit` is used instead.
>
> format.numbered::
> - A boolean which can enable sequence numbers in patch subjects.
> - Setting this option to "auto" will enable it only if there is
> - more than one patch. See --numbered option in
> - linkgit:git-format-patch[1].
> + A boolean which can enable or disable sequence numbers in patch
> + subjects. It defaults to "auto" which enables it only if there
> + is more than one patch. It can be enabled or disabled for all
> + messages by setting it to "true" or "false". See --numbered
> + option in linkgit:git-format-patch[1].
>
> format.headers::
> Additional email headers to include in a patch to be submitted
> diff --git a/Documentation/git-format-patch.txt b/Documentation/git-
> format-patch.txt
> index adb4ea7..ac36ce8 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -58,8 +58,10 @@ output, unless the --stdout option is specified.
> If -o is specified, output files are created in <dir>. Otherwise
> they are created in the current working directory.
>
> -If -n is specified, instead of "[PATCH] Subject", the first line
> -is formatted as "[PATCH n/m] Subject".
> +By default, the subject of a single patch is "[PATCH] First Line" and
> +the subject when multiple patches are output is "[PATCH n/m] First
> +Line". To force 1/1 to be added for a single patch, use -n. To omit
> +patch numbers from the subject, use -N
>
> If given --thread, 'git-format-patch' will generate In-Reply-To and
> References headers to make the second and subsequent patch mails
> appear
> @@ -81,7 +83,7 @@ include::diff-options.txt[]
>
> -n::
> --numbered::
> - Name output in '[PATCH n/m]' format.
> + Name output in '[PATCH n/m]' format, even with a single patch.
>
> -N::
> --no-numbered::
> diff --git a/builtin-log.c b/builtin-log.c
> index fc5e4da..93987ee 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -426,7 +426,7 @@ static int istitlechar(char c)
>
> static const char *fmt_patch_suffix = ".patch";
> static int numbered = 0;
> -static int auto_number = 0;
> +static int auto_number = 1;
>
> static char **extra_hdr;
> static int extra_hdr_nr;
> @@ -485,6 +485,7 @@ static int git_format_config(const char *var,
> const char *value, void *cb)
> return 0;
> }
> numbered = git_config_bool(var, value);
> + auto_number &&= numbered;
> return 0;
> }
>
> --
> 1.6.0.2.589.gcd70
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] format-patch: autonumber by default
From: Brian Gernhardt @ 2008-10-02 20:55 UTC (permalink / raw)
To: Git List
Cc: Giuseppe Bilotta, Jakub Narebski, Johannes Schindelin,
Shawn O. Pearce, Andreas Ericsson
In-Reply-To: <91634D16-B28A-4458-97A9-C469B5AF4E5D@silverinsanity.com>
format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. Users that want to
change the default behavior can use the format.numbering config key.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
_This_ patch changes the default and makes the config variable act
properly. Does not pass tests. 4014 and 4021 would have to be
updated for the new defaults.
Documentation/config.txt | 9 +++++----
Documentation/git-format-patch.txt | 8 +++++---
builtin-log.c | 3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index da18a54..5ba3ffa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -640,10 +640,11 @@ fetch.unpackLimit::
`transfer.unpackLimit` is used instead.
format.numbered::
- A boolean which can enable sequence numbers in patch subjects.
- Setting this option to "auto" will enable it only if there is
- more than one patch. See --numbered option in
- linkgit:git-format-patch[1].
+ A boolean which can enable or disable sequence numbers in patch
+ subjects. It defaults to "auto" which enables it only if there
+ is more than one patch. It can be enabled or disabled for all
+ messages by setting it to "true" or "false". See --numbered
+ option in linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index adb4ea7..ac36ce8 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -58,8 +58,10 @@ output, unless the --stdout option is specified.
If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
-If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
+By default, the subject of a single patch is "[PATCH] First Line" and
+the subject when multiple patches are output is "[PATCH n/m] First
+Line". To force 1/1 to be added for a single patch, use -n. To omit
+patch numbers from the subject, use -N
If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
@@ -81,7 +83,7 @@ include::diff-options.txt[]
-n::
--numbered::
- Name output in '[PATCH n/m]' format.
+ Name output in '[PATCH n/m]' format, even with a single patch.
-N::
--no-numbered::
diff --git a/builtin-log.c b/builtin-log.c
index fc5e4da..ee7c34e 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -426,7 +426,7 @@ static int istitlechar(char c)
static const char *fmt_patch_suffix = ".patch";
static int numbered = 0;
-static int auto_number = 0;
+static int auto_number = 1;
static char **extra_hdr;
static int extra_hdr_nr;
@@ -485,6 +485,7 @@ static int git_format_config(const char *var, const char *value, void *cb)
return 0;
}
numbered = git_config_bool(var, value);
+ auto_number = auto_number && numbered;
return 0;
}
--
1.6.0.2.589.gcd70
^ permalink raw reply related
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