* Re: [PATCH] cvsserver: Complete rewrite of the configuration parser
From: Junio C Hamano @ 2007-05-12 22:43 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Martin Langhoff
In-Reply-To: <20070512213153.GC7184@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Sat, May 12, 2007 at 12:59:49PM -0700, Junio C Hamano wrote:
>> But all of this is post 1.5.2 material; we would want to have a
>> minimal fixup on 'master' before 1.5.2, independent of this
>> rewrite.
>
> Fair enough. So far I see three very minimal solutions, but I can't
> decide which one is the least ugly:
>
> (For all we can begin by limiting the used variables to
> ^gitcvs.((ext|pserver).)? )
That sounds sensible. And ignore anything that do not match.
> 1) Drop variables named gitcvs.ext and gitcvs.pserver manually
I do not see any need for this; gitcvs.ext or gitcvs.pserver as
variables do not exist, at least right now. The breakage was
purely that the old parser tried to parse things it does not
even know about (e.g. diff.color) without knowing the rules
there.
> 2) Use the complete variable name as key to the hash instead of
> using a hash of hashes of hashes
> { "diff.color => "auto",
> "diff.color.whitespace" => "blue reverse" }
No need for this nor the next one either. You understand only
gitcvs.<option> or gitcvs.<method>.<option>, and you know there
is no string that is common in <option> and <method>
> 3) Make the second level always a hash, instead of using a string
> directly, so that Junio's example would look like this
> { diff => { color => { value => "auto",
> whitespace => "blue reverse" } } }
>
>
> Opinions?
^ permalink raw reply
* Re: [PATCH] Minor fixup to documentation of hooks in git-receive-pack.
From: Junio C Hamano @ 2007-05-12 22:46 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070512214311.GA13381@efreet.light.src>
Thanks.
^ permalink raw reply
* Re: Rebase max-pack-size?
From: Junio C Hamano @ 2007-05-12 22:57 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <56b7f5510705121325h65c62147h2b633fdddaece0be@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> Since max-pack-size has appeared, and disappeard, in "pu" twice
> and never made it into "next", I'm guessing I should rebase/merge it on
> top of the other recent pack-objects work. I may get to this tonight;
> perhaps I'll send the patchset in one email with multiple attachments?
I am still holding onto the series on its own topic branch, but
merging it to 'pu' and resolving conflicts seem pointless while
I am (and hopefully the rest of the list ought to be ;-)
primarily concentrating on last-minute bugfixes in preparation
for v1.5.2.
A rebase to be queued in 'next' would be good, though.
Thanks.
^ permalink raw reply
* Re: [RFC] format-patch stuff
From: david @ 2007-05-12 22:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705121109520.18541@iabervon.org>
On Sat, 12 May 2007, Daniel Barkalow wrote:
> It would be nice if git-format-patch would generate a [PATCH 0/n] message
> at the start of the series if some option were given. This would, of
> course, have to be editted afterwards to include actual information, but
> it would at least be pre-generated in series and with the configured
> headers and such.
instead of the 0/n message be empty, have it start off listing the subject
lines of the patches to follow (makeing it easier to add any comments
about them)
David Lang
^ permalink raw reply
* Re: [PATCH] link to HTML version of external doc if available
From: J. Bruce Fields @ 2007-05-12 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b21281h.fsf@assigned-by-dhcp.cox.net>
On Sat, May 12, 2007 at 11:47:38AM -0700, Junio C Hamano wrote:
> Currently
>
> $ git grep '\([^t]\|^\)'link: user-manual.txt
>
> gives four hits that refer to .txt version of the documentation
> set, but at least "hooks" and "cvs-migration" have HTML variants
> installed, so refer to them instead.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Oops, makes sense to me, thanks!
Acked-by: "J. Bruce Fields" <bfields@citi.umich.edu>
--b.
^ permalink raw reply
* Re: [RFC] format-patch stuff
From: Junio C Hamano @ 2007-05-12 23:03 UTC (permalink / raw)
To: david; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0705121553300.31357@asgard.lang.hm>
david@lang.hm writes:
> On Sat, 12 May 2007, Daniel Barkalow wrote:
>
>> It would be nice if git-format-patch would generate a [PATCH 0/n] message
>> at the start of the series if some option were given. This would, of
>> course, have to be editted afterwards to include actual information, but
>> it would at least be pre-generated in series and with the configured
>> headers and such.
>
> instead of the 0/n message be empty, have it start off listing the
> subject lines of the patches to follow (makeing it easier to add any
> comments about them)
Sounds sane. "git-format-patch -n --cover origin..master"?
^ permalink raw reply
* Re: suggestions for gitweb
From: Aaron Gray @ 2007-05-12 23:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net>
>> * the history/log pages could contain some statistics for the commits
>> like
>> the number of files changed and lines added/removed
>
> Probably.
>
> The three last items should be relatively easy, if somebody is
> interested. Pasky, Jakub, what do you think?
I would like to see lines of code and file sizes too.
Aaron
^ permalink raw reply
* Re: [PATCH] Document subproject feature
From: J. Bruce Fields @ 2007-05-12 23:18 UTC (permalink / raw)
To: Amos Waterland; +Cc: git
In-Reply-To: <20070512005844.GA24184@us.ibm.com>
On Fri, May 11, 2007 at 08:58:44PM -0400, Amos Waterland wrote:
> Add a section to the user manual about the new subproject support.
> Show how to make a subproject.
Looks like a great idea. It'll be nice to fill this out with some
details--http://marc.info/?l=git&m=117885769320212&w=2 might provide
some starting points.
--b.
^ permalink raw reply
* [BUG] git config gets confused
From: Frank Lichtenheld @ 2007-05-12 23:52 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
While working on test cases for git-cvsserver, especially the config
file handling I noticed the following bug in git-config:
$ git-config gitcvs.enabled true
$ git-config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite
$ git-config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite
expected result:
[gitcvs]
enabled = true
dbname = %Ggitcvs2.%a.%m.sqlite
[gitcvs "ext"]
dbname = %Ggitcvs1.%a.%m.sqlite
actual result:
[gitcvs]
enabled = true
[gitcvs "ext"]
dbname = %Ggitcvs1.%a.%m.sqlite
dbname = %Ggitcvs2.%a.%m.sqlite
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Git Wiki after engine update lost macros; special pages like RecentChanges do not work
From: Jakub Narebski @ 2007-05-12 15:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <200705110304.23115.jnareb@gmail.com>
Jakub Narebski wrote:
> After wiki engine (MoinMoin) update at http://git.or.cz/gitwiki MoinMoin
> macros like {{RecentChanges}} or {{SystemInfo}} (by the way, somehow
> link to SystemInfo was lost on FrontPage). It looks like some
> configuration related to using Wikipedia-like links syntax was lost:
>
> * You can make links using [[linkname]] (or even [[target|label]]
> * If you ever need to use macros here, use a {{macroname}} syntax.
>
> The second part is lost.
It looks like the problem is caused by stale caches of wiki pages.
I was able to make RecentChanges page work by choosing "Delete Cache"
action from combo box, but this solution doesn't work for example on
template page to create new pages. So currently you cannot create
new pages on GitWiki.
Pasky, could you please remove / delete cache? TIA.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH (amend)] gitweb: Check if requested object exists
From: Jakub Narebski @ 2007-05-12 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzm4a7sv3.fsf@assigned-by-dhcp.cox.net>
Try to avoid "Use of uninitialized value ..." errors caused by bad
revision, incorrect filename, wrong object id, bad file etc. (wrong
value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
server errors log.
Correct git_get_hash_by_path and parse_commit_text (and, in turn,
parse_commit) to return undef if object does not exist. Check in
git_tag if requested tag exists.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch is replacement of earlier "bandaid" patch
[PATCH] gitweb: Avoid "Use of uninitialized value" errors (written to logs)
Message-Id: <200705120135.30150.jnareb@gmail.com>
This one tries to cure causes, not put bandaid over symptoms.
It also passes my gitweb test.
One thing that is left is to fix "Use of initialized value..." warnings
for empty repositories (initialized, but without any commits). But I
don't think that this corner case is terribly important.
gitweb/gitweb.perl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 21864c6..74556f7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1060,6 +1060,11 @@ sub git_get_hash_by_path {
my $line = <$fd>;
close $fd or return undef;
+ if (!defined $line) {
+ # there is no tree or hash given by $path at $base
+ return undef;
+ }
+
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/;
if (defined $type && $type ne $2) {
@@ -1376,8 +1381,12 @@ sub parse_commit_text {
pop @commit_lines; # Remove '\0'
+ if (! @commit_lines) {
+ return;
+ }
+
my $header = shift @commit_lines;
- if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
+ if ($header !~ m/^[0-9a-fA-F]{40}/) {
return;
}
($co{'id'}, my @parents) = split ' ', $header;
@@ -3409,6 +3418,11 @@ sub git_tag {
git_header_html();
git_print_page_nav('','', $head,undef,$head);
my %tag = parse_tag($hash);
+
+ if (! %tag) {
+ die_error(undef, "Unknown tag object");
+ }
+
git_print_header_div('commit', esc_html($tag{'name'}), $hash);
print "<div class=\"title_text\">\n" .
"<table cellspacing=\"0\">\n" .
--
1.5.1.4
^ permalink raw reply related
* Re: suggestions for gitweb
From: Michael Niedermayer @ 2007-05-13 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <7v8xbtwtsy.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
Hi
On Sat, May 12, 2007 at 03:39:25PM -0700, Junio C Hamano wrote:
> Michael Niedermayer <michaelni@gmx.at> writes:
>
> > * gitweb uses many terms which are new to a non git user, and while
> > devlopers who work on ffmpeg will very likely very quickly have
> > figured out the meaning of all of them. i think simple users who just
> > want to browse the ffmpeg code will have their problems, so i belive
> > a small help text linked to from all pages which contains a short
> > definition of all the git(web) specific terms would be very helpfull
> > something like
> > blob - file at a specific revission/date
> > tree - directory at a specific revission/date
> > (short) log - project wide commit log
> > history - short log equivalent for a file or directory
>
> Coming fron non-CVS camp, I think changing this to non-git terms
> is very harmful than educating users who are migrating from
> other systems.
you must missunderstand me :(
i want to educate them, but i cannot as iam not speaking about ffmpeg
developers/contributors but rather random people who are curious and
want to take a look at the ffmpeg source
for them a simple help link similar to "ViewVC Help" which viewvc has
on the bottom right of its pages would be great IMHO
also the text above is a pure random suggestion by a svn user and was
not intended to redefine any git terms
>
> > * The color of adjacent blame "hunks" is so similar that its
> > indistinguishable on my notebook TFT when iam looking at it from slightly
> > above
>
> This is more or less intentional to make the difference not too
> distracting. I thought it was controlled via css which
> something you can use browser side tricks to suite your taste?
i sure can, i just thought the default was less than optimal
>
> > * The blame page shows the SHA1 for each hunk and IMHO thats the last thing
> > i would want to see first, id be much more interrested in by whom and
> > when a given change was done, iam wondering in which case the SHA1 would
> > be usefull? copy-paste onto your command line git tools but then why
> > use gitweb at all, 'git blame' would make more sense IMHO and a simple
> > click would reveal the sha1 with more info anyway ...
>
> They serve no purpose other than showing something to click on,
> and allow you to hover over (some people argued in the past
> that they recognize certain commit object names, but honestly I
> would not believe them). However, I do not think there are much
> better alternatives. Try coming up with a different "label"
> string that is of uniform length across commits, and does not
> chew up too much screen real estate.
trivial
the first N chars of the username + YYMMDD
so for example:
michaeln070612
or with space:
michaeln 070612
[...]
> > * on the history page there are "blob", "commitdiff" and "diff to current"
> > the obvious missing one is "diff to previous" which would be the diff to
> > the previous blob of this file
>
> Isn't that commitdiff, or commitdiff on that page does not limit
> the diff to the blob?
commitdiff doesnt limit it to the blob ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] cvsserver: Limit config parser to needed options
From: Frank Lichtenheld @ 2007-05-13 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <7v3b21wtlf.fsf@assigned-by-dhcp.cox.net>
Change the configuration parser so that it ignores
everything except for ^gitcvs.((ext|pserver).)?
This greatly reduces the risk of failing while
parsing some unknown and irrelevant config option.
The bug that triggered this change was that the
parsing doesn't handle sections that have a
subsection and a variable with the same name.
While this bug still remains, all remaining
causes can be attributed to user error, since
there are no defined variables gitcvs.ext and
gitcvs.pserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 3e7bf5b..a07c725 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -183,9 +183,9 @@ sub req_Root
}
foreach my $line ( @gitvars )
{
- next unless ( $line =~ /^(.*?)\.(.*?)(?:\.(.*?))?=(.*)$/ );
- unless ($3) {
- $cfg->{$1}{$2} = $4;
+ next unless ( $line =~ /^(gitcvs)\.(?:(ext|pserver)\.)?([\w-]+)=(.*)$/ );
+ unless ($2) {
+ $cfg->{$1}{$3} = $4;
} else {
$cfg->{$1}{$2}{$3} = $4;
}
--
1.5.1.4
^ permalink raw reply related
* [PATCH/RFC] cvsserver: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-13 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff, Frank Lichtenheld
Add a few test cases for the config file parsing
done by git-cvsserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9420-git-cvsserver-config.sh | 108 +++++++++++++++++++++++++++++++++++++++
1 files changed, 108 insertions(+), 0 deletions(-)
create mode 100755 t/t9420-git-cvsserver-config.sh
The RFC part is test 4 (gitcvs.ext.enabled = false).
With the current code it fails, with my GITCVS::config
patch it succeeds. I think the documentation currently
states ('method specific options "override" general options')
it should succeed and I guess that would be the more
intuitive behaviour. Anyone disagree?
diff --git a/t/t9420-git-cvsserver-config.sh b/t/t9420-git-cvsserver-config.sh
new file mode 100755
index 0000000..53550e8
--- /dev/null
+++ b/t/t9420-git-cvsserver-config.sh
@@ -0,0 +1,108 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Frank Lichtenheld
+#
+
+test_description='git-cvsserver configuration handling
+
+tests the parsing and handling of the git configuration
+by git-cvsserver'
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvsserver tests, cvs not found' :
+ test_done
+ exit
+fi
+perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+ test_expect_success 'skipping git-cvsserver tests, Perl SQLite interface unavailable' :
+ test_done
+ exit
+}
+
+unset GIT_DIR GIT_CONFIG
+WORKDIR=$(pwd)
+SERVERDIR=$(pwd)/gitcvs.git
+CVSROOT=":fork:$SERVERDIR"
+CVSWORK=$(pwd)/cvswork
+CVS_SERVER=git-cvsserver
+export CVSROOT CVS_SERVER
+
+rm -rf "$CVSWORK" "$SERVERDIR"
+echo >empty &&
+ git add empty &&
+ git commit -q -m "First Commit" &&
+ git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+ exit 1
+
+# note that cvs doesn't accept absolute pathnames
+# as argument to co -d
+test_expect_success 'basic checkout' \
+ 'cvs -Q co -d cvswork master &&
+ test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
+
+test_expect_success 'gitcvs.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ if cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.ext.enabled = true' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.ext.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled false &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ if cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs.%a.%m.sqlite &&
+ cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs.ext.master.sqlite"'
+
+rm -fr cvswork2
+
+# currently fails due to a git-config bug
+#test_expect_success 'gitcvs.ext.dbname' \
+# 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+# GIT_DIR="$SERVERDIR" git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
+# GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
+# cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+# diff -q cvswork cvswork2 &&
+# test -f "$SERVERDIR/gitcvs1.ext.master.sqlite" &&
+# test ! -f "$SERVERDIR/gitcvs2.ext.master.sqlite" &&
+# cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs1.ext.master.sqlite"'
+
+
+test_done
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] gitweb: choose appropriate view for file type if a= parameter missing
From: Jakub Narebski @ 2007-05-13 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <20070510073207.21562.qmail@25d0c789693af2.315fe32.mid.smarden.org>
<opublikowany i wysłany>
[Cc: Gerrit Pape <pape@smarden.org>, Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org]
Gerrit Pape wrote:
> this change would aid the creation of shortcuts to git repositories using
> simple substitution, such as:
> http://example.org/git/?p=path/to/repo.git;hb=HEAD;f=%s
>
> With this patch, if given the hash through the h= parameter, or the hash
> base (hb=) and a filename (f=), gitweb uses cat-file -t to automatically set
> the a= parameter.
> -if (defined $project) {
> - $action ||= 'summary';
> -} else {
> - $action ||= 'project_list';
> +if (!defined $action) {
> + if (defined $hash) {
> + $action = git_get_type($hash);
> + } elsif (defined $hash_base && defined $file_name) {
> + $action = git_get_type("$hash_base:$file_name");
> + } elsif (defined $project) {
> + $action = 'summary';
> + } else {
> + $action = 'project_list';
> + }
NOTE:
We have something similar for the only committag we support, namely
the shortened sha1 of object, which leads to an "object", which chooses
appropriate view using git_get_type / git-cat-file -t.
But contrary to the above solution it does it by creating a _redirect_
to a proper view, instead of silently selecting proper view like in
a patch above. Creating a redirect allows price for invoking
git-cat-file -t to be paid only once. User would bookmark correct view.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: suggestions for gitweb
From: Jakub Narebski @ 2007-05-13 0:41 UTC (permalink / raw)
To: git
In-Reply-To: <1f3701c794eb$5ff781b0$0200a8c0@AMD2500>
Aaron Gray wrote:
>>> * the history/log pages could contain some statistics for the commits
>>> like the number of files changed and lines added/removed
>>
>> Probably.
>>
>> The three last items should be relatively easy, if somebody is
>> interested. Pasky, Jakub, what do you think?
>
> I would like to see lines of code and file sizes too.
Diff statistics for difftree / whatchanged, or diff shortstat is a bit
costly, as it needs to generate and examine diff, and not only compare
trees. Besides --numstat doesn't support renames well now, but that
might not be an obstacle.
Lines of code and file sizes: file size needs additional invocation
per each file for gitweb; it would be easier for cgit. Costly! Counting
LOC is even more costly: take note that 1.) gitweb operates directly
on repository / object database, and does not use working area,
2.) git is snapshot based and not changeset based.
Of course like in the case of other costly features this migh be enabled
at will using %feature hash...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH (amend)] cvsserver: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-13 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frank Lichtenheld
In-Reply-To: <11790154701376-git-send-email-frank@lichtenheld.de>
Add a few test cases for the config file parsing
done by git-cvsserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9420-git-cvsserver-config.sh | 109 +++++++++++++++++++++++++++++++++++++++
1 files changed, 109 insertions(+), 0 deletions(-)
create mode 100755 t/t9420-git-cvsserver-config.sh
Forgot to copy the changes from Junio's GIT_CONFIG fix.
diff --git a/t/t9420-git-cvsserver-config.sh b/t/t9420-git-cvsserver-config.sh
new file mode 100755
index 0000000..e65d093
--- /dev/null
+++ b/t/t9420-git-cvsserver-config.sh
@@ -0,0 +1,109 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Frank Lichtenheld
+#
+
+test_description='git-cvsserver configuration handling
+
+tests the parsing and handling of the git configuration
+by git-cvsserver'
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvsserver tests, cvs not found' :
+ test_done
+ exit
+fi
+perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
+ test_expect_success 'skipping git-cvsserver tests, Perl SQLite interface unavailable' :
+ test_done
+ exit
+}
+
+unset GIT_DIR GIT_CONFIG
+WORKDIR=$(pwd)
+SERVERDIR=$(pwd)/gitcvs.git
+git_config="$SERVERDIR/config"
+CVSROOT=":fork:$SERVERDIR"
+CVSWORK=$(pwd)/cvswork
+CVS_SERVER=git-cvsserver
+export CVSROOT CVS_SERVER
+
+rm -rf "$CVSWORK" "$SERVERDIR"
+echo >empty &&
+ git add empty &&
+ git commit -q -m "First Commit" &&
+ git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+ exit 1
+
+# note that cvs doesn't accept absolute pathnames
+# as argument to co -d
+test_expect_success 'basic checkout' \
+ 'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
+ test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
+
+test_expect_success 'gitcvs.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.ext.enabled = true' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.ext.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled false &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+
+test_expect_success 'gitcvs.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs.%a.%m.sqlite &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs.ext.master.sqlite"'
+
+rm -fr cvswork2
+
+# currently fails due to a git-config bug
+#test_expect_success 'gitcvs.ext.dbname' \
+# 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+# GIT_DIR="$SERVERDIR" git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
+# GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
+# GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+# diff -q cvswork cvswork2 &&
+# test -f "$SERVERDIR/gitcvs1.ext.master.sqlite" &&
+# test ! -f "$SERVERDIR/gitcvs2.ext.master.sqlite" &&
+# cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs1.ext.master.sqlite"'
+
+
+test_done
--
1.5.1.4
^ permalink raw reply related
* Re: suggestions for gitweb
From: Junio C Hamano @ 2007-05-13 0:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f25mic$1b1$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Lines of code and file sizes: file size needs additional invocation
> per each file for gitweb; it would be easier for cgit. Costly! Counting
> LOC is even more costly: take note that 1.) gitweb operates directly
> on repository / object database, and does not use working area,
> 2.) git is snapshot based and not changeset based.
We earlier discussed to make --numstat to allow us add this kind
of information for easier script consumption.
Perhaps instead of modifying --numstat, we may be better off to
add another format that can be more easily extended to support
other things, like we do for the --porcelain format out of
git-blame? It does not have to be one line per record, like the
way --numstat was done, which was primarily in order to make it
a compact, human readable format.
^ permalink raw reply
* Re: [PATCH 0/3] Fix assorted white space damage
From: Junio C Hamano @ 2007-05-13 1:45 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550705120409v629425aesc910927c26871323@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> Following there is a 3 patch series to remove stealth whitespace.
>
> I have used the new 'cleanfile' script by H. Peter Anvin, just merged
> in Linux tree.
>
> The script cleans up various classes of stealth whitespace. In
> particular, it cleans up:
>
> - Whitespace (spaces or tabs)before newline;
> - DOS line endings (CR before LF);
> - Space before tab (spaces are deleted or converted to tabs);
> - Empty lines at end of file.
I haven't checked the script, but "git-apply --whitespace=strip"
can be used to do pretty much the same job with this sequence,
except the last one (do it with a copy of repository if you do
not want "git clean -x" to lose untracked):
$ git checkout master
$ rm -f .git/index
$ git checkout HEAD -- t/
$ git clean -x -d
$ git diff -R --binary HEAD >P.diff
$ git apply --index --whitespace=strip P.diff
Then you can check the results, and make a commit.
In the above I explicitly "saved" t/ because we have some test
vectors that need to have trailing whitespaces.
^ permalink raw reply
* Re: [PATCH 0/3] Fix assorted white space damage
From: Marco Costalba @ 2007-05-13 3:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vhcqhwz2n.fsf@assigned-by-dhcp.cox.net>
On 5/12/07, Junio C Hamano <junkio@cox.net> wrote:
> Allow me to chuck these at this moment. Could you redo this as
> the first thing after v1.5.2 final, please?
>
>
Ok. I will be off-line for the next week.
I will redo when coming back.
Marco
^ permalink raw reply
* Re: [PATCH] Allow fetching references from any namespace
From: Marco Costalba @ 2007-05-13 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vveey4gt0.fsf@assigned-by-dhcp.cox.net>
On 5/12/07, Junio C Hamano <junkio@cox.net> wrote:
>
> Sounds like it is not even a regression but just was not
> supposed to work from the beginning.
>
> Not that I think lifting that restriction is a bad idea,
> though.
>
> -
> 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
>
Please consider that StGIT put patch names under refs/patches and
probably we don't want to see them.
I'm very sorry but I cannot test my-self because I'm leaving now. I
have just seen the patch applied in git tree and this thing come to my
mind.
Marco
^ permalink raw reply
* Re: [BUG] git config gets confused
From: Junio C Hamano @ 2007-05-13 4:49 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Johannes Schindelin
In-Reply-To: <20070512235230.GE7184@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> While working on test cases for git-cvsserver, especially the config
> file handling I noticed the following bug in git-config:
>
> $ git-config gitcvs.enabled true
> $ git-config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite
> $ git-config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite
>
> expected result:
>
> [gitcvs]
> enabled = true
> dbname = %Ggitcvs2.%a.%m.sqlite
> [gitcvs "ext"]
> dbname = %Ggitcvs1.%a.%m.sqlite
>
> actual result:
>
> [gitcvs]
> enabled = true
> [gitcvs "ext"]
> dbname = %Ggitcvs1.%a.%m.sqlite
> dbname = %Ggitcvs2.%a.%m.sqlite
Oh, boy.
Why am I not surprised by another bug in config writer?
Dscho, does this look good?
-- >8 --
git-config: do not forget "a.b.var" already ends "a.var" section.
Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way. Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
config.c | 26 ++++++++++++++++++++++----
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index 70d1055..70e6e7e 100644
--- a/config.c
+++ b/config.c
@@ -451,6 +451,9 @@ static int matches(const char* key, const char* value)
static int store_aux(const char* key, const char* value)
{
+ const char *ep;
+ size_t section_len;
+
switch (store.state) {
case KEY_SEEN:
if (matches(key, value)) {
@@ -468,12 +471,27 @@ static int store_aux(const char* key, const char* value)
}
break;
case SECTION_SEEN:
- if (strncmp(key, store.key, store.baselen+1)) {
+ /*
+ * What we are looking for is in store.key (both
+ * section and var), and its section part is baselen
+ * long. We found key (again, both section and var).
+ * We would want to know if this key is in the same
+ * section as what we are looking for.
+ */
+ ep = strrchr(key, '.');
+ section_len = ep - key;
+
+ if ((section_len != store.baselen) ||
+ memcmp(key, store.key, section_len+1)) {
store.state = SECTION_END_SEEN;
break;
- } else
- /* do not increment matches: this is no match */
- store.offset[store.seen] = ftell(config_file);
+ }
+
+ /*
+ * Do not increment matches: this is no match, but we
+ * just made sure we are in the desired section.
+ */
+ store.offset[store.seen] = ftell(config_file);
/* fallthru */
case SECTION_END_SEEN:
case START:
^ permalink raw reply related
* [PATCH] git-config: test for 'do not forget "a.b.var" already ends "a.var" section'.
From: Steffen Prohaska @ 2007-05-13 7:12 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
Added test for mentioned bugfix.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t1300-repo-config.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 78c2e08..91d572c 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -407,6 +407,22 @@ EOF
test_expect_success "section was removed properly" \
"git diff -u expect .git/config"
+rm .git/config
+
+git-config gitcvs.enabled true
+git-config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite
+git-config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite
+
+cat > expect << EOF
+[gitcvs]
+ enabled = true
+ dbname = %Ggitcvs2.%a.%m.sqlite
+[gitcvs "ext"]
+ dbname = %Ggitcvs1.%a.%m.sqlite
+EOF
+
+test_expect_success 'section ending' 'cmp .git/config expect'
+
test_expect_success numbers '
git-config kilo.gram 1k &&
--
1.5.1.2
^ permalink raw reply related
* Re: [PATCH] Allow fetching references from any namespace
From: Jan Hudec @ 2007-05-13 7:24 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <e5bfff550705122048s6772db3as63f6fb23fe7e1bd7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]
On Sun, May 13, 2007 at 05:48:00 +0200, Marco Costalba wrote:
> On 5/12/07, Junio C Hamano <junkio@cox.net> wrote:
> >
> >Sounds like it is not even a regression but just was not
> >supposed to work from the beginning.
> >
> >Not that I think lifting that restriction is a bad idea,
> >though.
> >
> >-
> >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
> >
>
> Please consider that StGIT put patch names under refs/patches and
> probably we don't want to see them.
If you don't add them to the push configuration, you won't see them.
> I'm very sorry but I cannot test my-self because I'm leaving now. I
> have just seen the patch applied in git tree and this thing come to my
> mind.
It does not make them pushed. It just allows pushing them--which is good
thing sometimes (eg. if you use push to backup the repo).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-svn: don't drop the username from URLs when dcommit is run
From: Eric Wong @ 2007-05-13 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Eisenhardt, Adam Roben, Git Mailing List
In-Reply-To: <20070512214035.GA18560@muzzle>
Eric Wong <normalperson@yhbt.net> wrote:
> Martin Eisenhardt <list-receive@mneisen.org> wrote:
>
> Thanks for the bug report. I haven't tested the patch below, so
> let me know if it works:
Junio: I've confirmed this patch works, please apply. Thanks.
>From 58af622c222514dc3da938ce6309e1ac927a9574 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 12 May 2007 14:36:20 -0700
Subject: [PATCH] git-svn: don't drop the username from URLs when dcommit is run
We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3c4f490..d74e6d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -393,7 +393,7 @@ sub cmd_dcommit {
} else {
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
- ra => Git::SVN::Ra->new($url),
+ ra => Git::SVN::Ra->new($gs->full_url),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
--
Eric Wong
^ 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