* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Alexander Litvinov @ 2006-06-20 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveqw82qd.fsf@assigned-by-dhcp.cox.net>
> "will" meaning "you suspect" or "you tried and confirmed"?
:-) I suspect.
Lets test. Your pu branch (5af05efbeaa06005596129fb111a739a87f8a883) really
works. I have cvs repo and use git for daily work. I have head and 2 branches
from cvs and store CVS/* files in git too. Usualy this operation pruduce a
lot of CVS/Tag files:
git checkout -f cvs-v52 (this is one of by cvs's branch)
cvs -q up -dP (nothing have been updated)
git checkout -f master (this is a dev branch from cvs head)
git status
pu branch nuke them when use git checkout -f !
^ permalink raw reply
* upload-pack is unsafe in corrupt repository
From: Junio C Hamano @ 2006-06-20 12:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I was helping Andrew fetching from maintainer trees. One of the
trees were corrupt (i.e. git-fsck-objects unclean) and there was
a rather grave consequences we found out the hard way (and it is
5am but Tuesday is not my git day X-<).
upload-pack forks a pipeline, whose upstream execs rev-list and
downstream execs pack-objects. rev-list correctly notices that
it cannot reach some objects and dies, but pack-objects just
says "Ah, the list of object input just ended -- let's send them
all". This results in git-fetch-pack to be fed an incomplete
pack. However, git-unpack-objects is happy (the pack is not
corrupt, just that it does not contain what the protocol
exchange expected to send) and git-fetch-pack ends up going all
the way through updating the ref.
Eek.
At this moment, I am just reporting this because I am too tired
to code it myself right now, but I think the fix is to make
upload-pack to fork once more, waitpid() for rev-list and
inject/append garbage in the stream pack-objects produces, in
order to cause unpack-objects (or index-pack) that runs on the
the fetching end to notice, when rev-list or pack-objects barf.
Of course a nicer fix is to add the sideband we have been
discussing about, but that relies on protocol extension and
would not solve the problem for older clients.
Side note: in my head, the sideband would work by the "forked
once more" upload-pack process to listen to both stdout and
stderr of pack-objects, and feed them packetized (instead of the
current "go-straight-stream") by perhaps prefixing them with one
byte (is this a payload, or is this a progress-bar/keepalive type
packet). Of course, this would change the way the payload is
transferred, so the initial handshake needs to negotiate if the
sideband should be used just like we do other new features like
thin pack transfers.
^ permalink raw reply
* [PATCH] gitweb: Start search from HEAD
From: Timo Hirvonen @ 2006-06-20 12:25 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Starting search from whatever the current "h" parameter points to is
wrong. Sometimes it doesn't give all the expected results or may even
fail if h points to an object which is not a commit.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
This patch is against the "next" branch.
gitweb/gitweb.cgi | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 78e6dd0..3ad23a3 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -292,14 +292,7 @@ EOF
if (!defined $searchtext) {
$searchtext = "";
}
- my $search_hash;
- if (defined $hash) {
- $search_hash = $hash;
- } else {
- $search_hash = "HEAD";
- }
$cgi->param("a", "search");
- $cgi->param("h", $search_hash);
print $cgi->startform(-method => "get", -action => $my_uri) .
"<div class=\"search\">\n" .
$cgi->hidden(-name => "p") . "\n" .
@@ -2328,9 +2321,7 @@ sub git_search {
if (!defined $searchtext) {
die_error("", "Text field empty.");
}
- if (!defined $hash) {
- $hash = git_read_head($project);
- }
+ $hash = "HEAD";
my %co = git_read_commit($hash);
if (!%co) {
die_error(undef, "Unknown commit object.");
--
1.4.0.gd281
^ permalink raw reply related
* Re: wrong check condition in patch-delta.c?
From: Nicolas Pitre @ 2006-06-20 12:28 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0606192332j5b2ee4b9ycf2c63c7b1820204@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 418 bytes --]
On Tue, 20 Jun 2006, Nguyn Thái Ngc Duy wrote:
> Hi,
> While inspecting patch-delta.c, I encounter this:
> if (cp_off + cp_size < cp_size ||
> cp_off + cp_size > src_size ||
> cp_size > size)
> goto bad;
> "cp_off + cp_size < cp_size" doesn't make sense to me. Is it on purpose?
Yes, it absolutely is.
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: Start search from HEAD
From: Junio C Hamano @ 2006-06-20 12:31 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060620152515.23e59396.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Starting search from whatever the current "h" parameter points to is
> wrong. Sometimes it doesn't give all the expected results or may even
> fail if h points to an object which is not a commit.
If h is not a commit, perhaps, but wouldn't you expect it to
find things from "next" branch if "h" points at it?
^ permalink raw reply
* Re: [PATCH] Restore SIGCHLD to SIG_DFL where we care about waitpid().
From: Petr Baudis @ 2006-06-20 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vslm04j2r.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Jun 20, 2006 at 05:11:40AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/connect.c b/connect.c
> index 52d709e..db7342e 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -581,6 +581,11 @@ int git_connect(int fd[2], char *url, co
> enum protocol protocol = PROTO_LOCAL;
> int free_path = 0;
>
> + /* Without this we cannot rely on waitpid() to tell
> + * what happened to our children.
> + */
> + signal(SIGCHLD, SIG_DFL);
> +
> host = strstr(url, "://");
> if(host) {
> *host = '\0';
It would be nice if at this point of Git development we could already
think about libification when doing things like this (I'd like to do
Git.pm as my little summer project this year). I'd make it part of the
API that the calling application must not defer SIGCHLD, and conversely
put the handler to all the main()s that reach git_connect().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] gitweb: Use $hash_base as $search_hash if possible
From: Timo Hirvonen @ 2006-06-20 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64iw80uo.fsf@assigned-by-dhcp.cox.net>
$hash (h parameter) does not always point to a commit. Use $hash_base as
$search_hash when it is defined.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > Starting search from whatever the current "h" parameter points to is
> > wrong. Sometimes it doesn't give all the expected results or may even
> > fail if h points to an object which is not a commit.
>
> If h is not a commit, perhaps, but wouldn't you expect it to
> find things from "next" branch if "h" points at it?
I did not change it to start search from tip of the branch. The
current behavior is somewhat confusing but at least it is consistent
with rest of gitweb. For example clicking shortlog link from commit
view shows the current commit at top of the list, not tip of the
current branch.
gitweb/gitweb.cgi | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 78e6dd0..7318512 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -293,7 +293,9 @@ EOF
$searchtext = "";
}
my $search_hash;
- if (defined $hash) {
+ if (defined $hash_base) {
+ $search_hash = $hash_base;
+ } elsif (defined $hash) {
$search_hash = $hash;
} else {
$search_hash = "HEAD";
--
1.4.0.gd281
^ permalink raw reply related
* Re: [PATCH] checkout -f: do not leave untracked working tree files.
From: Carl Worth @ 2006-06-20 14:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, git, Ryan Anderson
In-Reply-To: <7vfyi0b1gv.fsf_-_@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
On Tue, 20 Jun 2006 02:50:08 -0700, Junio C Hamano wrote:
>
> Earlier we did not consider untracked working tree files
> "precious", but we have always considered them fair game to
> clobber. These days, branch switching by read-tree is more
> careful and tries to protect untracked working tree files. This
> caused the following workflow to stop working:
>
> git checkout one-branch-with-file-F
> git checkout -f another-without-file-F
> git pull . one-branch-with-file-F
Another one that a colleague of mine hit is:
git checkout -b branch-without-file branch-with-file
git rm some-file
# Allow for some external changes on branch-with-file
git pull . branch-with-file
One possibility for fixing this case is to make git-rm delete the file
by default, (that is, act as if the current -f option is
passed). There's no real safety concern unless the file is dirty,
(could require -f again for that case).
> If this works out for Jeff, I can simply drop
> the "core.oktoclobber = ask" patch from my topics -- although
> I kind of liked that one ;-).
Fixing the behavior instead of adding configuration is definitely a
good plan.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: packs and trees
From: Jon Smirl @ 2006-06-20 14:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606192313l16b16132r1523f5e05ae1566a@mail.gmail.com>
On 6/20/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/20/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > The plan is to modify rcs2git from parsecvs to create all of the git
> > objects for the tree.
>
> Sounds like a good plan. Have you seen recent discussions about it
> being impossible to repack usefully when you don't have trees (and
> resulting performance problems on ext3).
No, I will look back in the archives. If needed we can do a repack
after each file is added. I would hope that git can handle a repack
when the new stuff is 100% deltas from a single file.
If I can't pack the exploded deltas need about 35GB disk space. That
is an awful lot to feed to pack all at once, but it will have trees,
>
> > cvs2svn seems to do a good job at generating the trees.
>
> No doubt. Gut the last stage, and use all the data in the intermediate
> DBs to run a git import. It's a great plan, and if you can understand
> that Python code... all yours ;-)
How hard would it be to adjust cvsps to use cvs2svn's algorithm for
grouping the changesets? I'd rather do this in a C app but I haven't
figured out the guts of parsecvs or cvsps well enough to change the
algorithms. There is no requirement to use external databases, sorting
everything in RAM is fine.
If you are interested in changing the cvsps grouping algorithm I can
look at moding it to write out the revisions as are they are parsed.
Then you only need to save the git sha1 in memory instead of the
file:rev when sorting.
> > exactly sure how the changeset detection algorithms in the three apps
> > compare, but cvs2svn is not having any trouble building changesets for
> > Mozilla. The other two apps have some issues, cvsps throws away some
> > of the branches and parsecvs can't complete the analysis.
>
> Have you tried a recent parsecvs from Keith's tree? There's been quite
> a bit of activity there too. And Keith's interested in sorting out
> incremental imports too, which you need for a reasonable Moz
> transition plan as well.
Keith's parsecvs run ended up in a loop and mine hit a parsecvs error
and then had memory corruption after about eight hours. That was last
week, I just checked the logs and I don't see any comments about
fixing it.
Even after spending eight hours building the changeset info iit is
still going to take it a couple of days to retrieve the versions one
at a time and write them to git. Reparsing 50MB delta files n^2/2
times is a major bottleneck for all three programs.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Log peer address when git-daemon called from inetd
From: David Woodhouse @ 2006-06-20 14:38 UTC (permalink / raw)
To: git; +Cc: jdl
When we run git-daemon from inetd, even with the --verbose option, it
doesn't log the peer address. That logic was only in the standalone
dæmon code -- move it to the execute() function instead. Tested with
both IPv6 and Legacy IP clients, in both inetd and dæmon mode.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Jon Loeliger <jdl@jdl.com>
diff --git a/daemon.c b/daemon.c
index 2f03f99..7d30302 100644
--- a/daemon.c
+++ b/daemon.c
@@ -264,11 +264,34 @@ static int upload(char *dir)
return -1;
}
-static int execute(void)
+static int execute(struct sockaddr *addr)
{
static char line[1000];
int pktlen, len;
+ if (addr) {
+ char addrbuf[256] = "";
+ int port = -1;
+
+ if (addr->sa_family == AF_INET) {
+ struct sockaddr_in *sin_addr = (void *) addr;
+ inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
+ port = sin_addr->sin_port;
+#ifndef NO_IPV6
+ } else if (addr && addr->sa_family == AF_INET6) {
+ struct sockaddr_in6 *sin6_addr = (void *) addr;
+
+ char *buf = addrbuf;
+ *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
+ inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
+ strcat(buf, "]");
+
+ port = sin6_addr->sin6_port;
+#endif
+ }
+ loginfo("Connection from %s:%d", addrbuf, port);
+ }
+
alarm(init_timeout ? init_timeout : timeout);
pktlen = packet_read_line(0, line, sizeof(line));
alarm(0);
@@ -414,8 +437,6 @@ static void check_max_connections(void)
static void handle(int incoming, struct sockaddr *addr, int addrlen)
{
pid_t pid = fork();
- char addrbuf[256] = "";
- int port = -1;
if (pid) {
unsigned idx;
@@ -436,26 +457,7 @@ static void handle(int incoming, struct
dup2(incoming, 1);
close(incoming);
- if (addr->sa_family == AF_INET) {
- struct sockaddr_in *sin_addr = (void *) addr;
- inet_ntop(AF_INET, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = sin_addr->sin_port;
-
-#ifndef NO_IPV6
- } else if (addr->sa_family == AF_INET6) {
- struct sockaddr_in6 *sin6_addr = (void *) addr;
-
- char *buf = addrbuf;
- *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
- inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
- strcat(buf, "]");
-
- port = sin6_addr->sin6_port;
-#endif
- }
- loginfo("Connection from %s:%d", addrbuf, port);
-
- exit(execute());
+ exit(execute(addr));
}
static void child_handler(int signo)
@@ -751,8 +753,16 @@ int main(int argc, char **argv)
}
if (inetd_mode) {
+ struct sockaddr_storage ss;
+ struct sockaddr *peer = (struct sockaddr *)&ss;
+ socklen_t slen = sizeof(ss);
+
fclose(stderr); //FIXME: workaround
- return execute();
+
+ if (getpeername(0, peer, &slen))
+ peer = NULL;
+
+ return execute(peer);
}
return serve(port);
--
dwmw2
^ permalink raw reply related
* [PATCH] gitweb: style done with stylesheet
From: Jakub Narebski @ 2006-06-20 14:58 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Replace (almost) all 'style' attributes with 'class' attribute
and adding rule to CSS file. Some tables use CSS for styling
instead of legacy styling attributes.
---
This patch needs readable CSS style file gitweb/gitweb.css
introduced in previous patch.
It applies on top of next.
gitweb/gitweb.cgi | 80 ++++++++++++++++++++++--------------------
gitweb/gitweb.css | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 136 insertions(+), 45 deletions(-)
eaa8afc21044fcce134777b35bdcfb3e97f8ab8f
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 1b254df..89224e6 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -252,6 +252,19 @@ sub unquote {
return $str;
}
+# CSS class for given age value (in seconds)
+sub age_class {
+ my $age = shift;
+
+ if ($age < 60*60*2) {
+ return "age0";
+ } elsif ($age < 60*60*24*2) {
+ return "age1";
+ } else {
+ return "age2";
+ }
+}
+
sub git_header_html {
my $status = shift || "200 OK";
my $expires = shift;
@@ -600,13 +613,13 @@ sub git_diff_print {
while (my $line = <$fd>) {
chomp($line);
my $char = substr($line, 0, 1);
- my $color = "";
+ my $diff_class = "";
if ($char eq '+') {
- $color = " style=\"color:#008800;\"";
+ $diff_class = " add";
} elsif ($char eq "-") {
- $color = " style=\"color:#cc0000;\"";
+ $diff_class = " rem";
} elsif ($char eq "@") {
- $color = " style=\"color:#990099;\"";
+ $diff_class = " chunk_header";
} elsif ($char eq "\\") {
# skip errors
next;
@@ -617,7 +630,7 @@ sub git_diff_print {
$line =~ s/\t/$spaces/;
}
}
- print "<div class=\"pre\"$color>" . esc_html($line) . "</div>\n";
+ print "<div class=\"diff$diff_class\">" . esc_html($line) . "</div>\n";
}
}
close $fd;
@@ -849,7 +862,7 @@ sub git_project_list {
close $fd;
print "</div>\n";
}
- print "<table cellspacing=\"0\">\n" .
+ print "<table class=\"project_list\">\n" .
"<tr>\n";
if (!defined($order) || (defined($order) && ($order eq "project"))) {
@projects = sort {$a->{'path'} cmp $b->{'path'}} @projects;
@@ -888,15 +901,7 @@ sub git_project_list {
print "<td>" . $cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=summary"), -class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
"<td>$pr->{'descr'}</td>\n" .
"<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
- my $colored_age;
- if ($pr->{'commit'}{'age'} < 60*60*2) {
- $colored_age = "<span style =\"color: #009900;\"><b><i>$pr->{'commit'}{'age_string'}</i></b></span>";
- } elsif ($pr->{'commit'}{'age'} < 60*60*24*2) {
- $colored_age = "<span style =\"color: #009900;\"><i>$pr->{'commit'}{'age_string'}</i></span>";
- } else {
- $colored_age = "<i>$pr->{'commit'}{'age_string'}</i>";
- }
- print "<td>$colored_age</td>\n" .
+ print "<td class=\"". age_class($pr->{'commit'}{'age'}) . "\">" . $pr->{'commit'}{'age_string'} . "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=summary")}, "summary") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$pr->{'path'};a=shortlog")}, "shortlog") .
@@ -1240,7 +1245,7 @@ sub git_blame {
print "<div class=\"page_path\"><b>" . esc_html($file_name) . "</b></div>\n";
print "<div class=\"page_body\">\n";
print <<HTML;
-<table style="border-collapse: collapse;">
+<table class="blame">
<tr>
<th>Commit</th>
<th>Age</th>
@@ -1261,7 +1266,7 @@ HTML
my $data;
my $age;
my $age_str;
- my $age_style;
+ my $age_class;
chomp $line;
$line_class_num = ($line_class_num + 1) % $line_class_len;
@@ -1273,16 +1278,14 @@ HTML
$lineno = $4;
$data = $5;
} else {
- print qq( <tr><td colspan="5" style="color: red; background-color: yellow;">Unable to parse: $line</td></tr>\n);
+ print qq( <tr><td colspan="5" class="error">Unable to parse: $line</td></tr>\n);
next;
}
$short_rev = substr ($long_rev, 0, 8);
$age = time () - $time;
$age_str = age_string ($age);
$age_str =~ s/ / /g;
- $age_style = 'font-style: italic;';
- $age_style .= ' color: #009900; background: transparent;' if ($age < 60*60*24*2);
- $age_style .= ' font-weight: bold;' if ($age < 60*60*2);
+ $age_class = age_class($age);
$author = esc_html ($author);
$author =~ s/ / /g;
# escape tabs
@@ -1293,15 +1296,14 @@ HTML
}
}
$data = esc_html ($data);
- $data =~ s/ / /g;
print <<HTML;
<tr class="$line_class[$line_class_num]">
- <td style="font-family: monospace;"><a href="$my_uri?${\esc_param ("p=$project;a=commit;h=$long_rev")}" class="text">$short_rev..</a></td>
- <td style="$age_style">$age_str</td>
+ <td class="sha1"><a href="$my_uri?${\esc_param ("p=$project;a=commit;h=$long_rev")}" class="text">$short_rev..</a></td>
+ <td class="$age_class">$age_str</td>
<td>$author</td>
- <td style="text-align: right;"><a id="$lineno" href="#$lineno" class="linenr">$lineno</a></td>
- <td style="font-family: monospace;">$data</td>
+ <td class="linenr"><a id="$lineno" href="#$lineno" class="linenr">$lineno</a></td>
+ <td class="pre">$data</td>
</tr>
HTML
} # while (my $line = <$fd>)
@@ -1646,7 +1648,7 @@ sub git_tree {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- print "<td style=\"font-family:monospace\">" . mode_str($t_mode) . "</td>\n";
+ print "<td class=\"mode\">" . mode_str($t_mode) . "</td>\n";
if ($t_type eq "blob") {
print "<td class=\"list\">" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$t_hash$base_key;f=$base$t_name"), -class => "list"}, esc_html($t_name)) .
@@ -1912,7 +1914,7 @@ sub git_commit {
"<tr>" .
"<td></td><td> $ad{'rfc2822'}";
if ($ad{'hour_local'} < 6) {
- printf(" (<span style=\"color: #cc0000;\">%02d:%02d</span> %s)", $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'});
+ printf(" (<span class=\"atnight\">%02d:%02d</span> %s)", $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'});
} else {
printf(" (%02d:%02d %s)", $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'});
}
@@ -1920,10 +1922,10 @@ sub git_commit {
"</tr>\n";
print "<tr><td>committer</td><td>" . esc_html($co{'committer'}) . "</td></tr>\n";
print "<tr><td></td><td> $cd{'rfc2822'}" . sprintf(" (%02d:%02d %s)", $cd{'hour_local'}, $cd{'minute_local'}, $cd{'tz_local'}) . "</td></tr>\n";
- print "<tr><td>commit</td><td style=\"font-family:monospace\">$co{'id'}</td></tr>\n";
+ print "<tr><td>commit</td><td class=\"sha1\">$co{'id'}</td></tr>\n";
print "<tr>" .
"<td>tree</td>" .
- "<td style=\"font-family:monospace\">" .
+ "<td class=\"sha1\">" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$co{'tree'};hb=$hash"), class => "list"}, $co{'tree'}) .
"</td>" .
"<td class=\"link\">" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") .
@@ -1933,7 +1935,7 @@ sub git_commit {
foreach my $par (@$parents) {
print "<tr>" .
"<td>parent</td>" .
- "<td style=\"font-family:monospace\">" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$par"), class => "list"}, $par) . "</td>" .
+ "<td class=\"sha1\">" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$par"), class => "list"}, $par) . "</td>" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$par")}, "commit") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$hash;hp=$par")}, "commitdiff") .
@@ -1958,7 +1960,7 @@ sub git_commit {
}
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
$signed = 1;
- print "<span style=\"color: #888888\">" . esc_html($line) . "</span><br/>\n";
+ print "<span class=\"signoff\">" . esc_html($line) . "</span><br/>\n";
} else {
$signed = 0;
print format_log_line_html($line) . "<br/>\n";
@@ -1970,7 +1972,7 @@ sub git_commit {
print(($#difftree + 1) . " files changed:\n");
}
print "</div>\n";
- print "<table cellspacing=\"0\">\n";
+ print "<table class=\"diff_tree\">\n";
my $alternate = 0;
foreach my $line (@difftree) {
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
@@ -1998,12 +2000,12 @@ sub git_commit {
}
print "<td>" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$to_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file)) . "</td>\n" .
- "<td><span style=\"color: #008000;\">[new " . file_type($to_mode) . "$mode_chng]</span></td>\n" .
+ "<td><span class=\"file_status new\">[new " . file_type($to_mode) . "$mode_chng]</span></td>\n" .
"<td class=\"link\">" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$to_id;hb=$hash;f=$file")}, "blob") . "</td>\n";
} elsif ($status eq "D") {
print "<td>" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$from_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file)) . "</td>\n" .
- "<td><span style=\"color: #c00000;\">[deleted " . file_type($from_mode). "]</span></td>\n" .
+ "<td><span class=\"file_status deleted\">[deleted " . file_type($from_mode). "]</span></td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$from_id;hb=$hash;f=$file")}, "blob") .
" | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=history;h=$hash;f=$file")}, "history") .
@@ -2011,7 +2013,7 @@ sub git_commit {
} elsif ($status eq "M" || $status eq "T") {
my $mode_chnge = "";
if ($from_mode != $to_mode) {
- $mode_chnge = " <span style=\"color: #777777;\">[changed";
+ $mode_chnge = " <span class=\"file_status mode_chnge\">[changed";
if (((oct $from_mode) & S_IFMT) != ((oct $to_mode) & S_IFMT)) {
$mode_chnge .= " from " . file_type($from_mode) . " to " . file_type($to_mode);
}
@@ -2047,7 +2049,7 @@ sub git_commit {
}
print "<td>" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$to_id;hb=$hash;f=$to_file"), -class => "list"}, esc_html($to_file)) . "</td>\n" .
- "<td><span style=\"color: #777777;\">[moved from " .
+ "<td><span class=\"file_status moved\">[moved from " .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$from_id;hb=$hash;f=$from_file"), -class => "list"}, esc_html($from_file)) .
" with " . (int $similarity) . "% similarity$mode_chng]</span></td>\n" .
"<td class=\"link\">" .
@@ -2407,7 +2409,7 @@ sub git_search {
my $match = esc_html($2) || "";
my $trail = esc_html($3) || "";
$trail = chop_str($trail, 30, 10);
- my $text = "$lead<span style=\"color:#e00000\">$match</span>$trail";
+ my $text = "$lead<span class=\"match\">$match</span>$trail";
print chop_str($text, 80, 5) . "<br/>\n";
}
}
@@ -2456,7 +2458,7 @@ sub git_search {
while (my $setref = shift @files) {
my %set = %$setref;
print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob;h=$set{'id'};hb=$co{'id'};f=$set{'file'}"), class => "list"},
- "<span style=\"color:#e00000\">" . esc_html($set{'file'}) . "</span>") .
+ "<span class=\"match\">" . esc_html($set{'file'}) . "</span>") .
"<br/>\n";
}
print "</td>\n" .
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index da53eb4..98410f5 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -89,14 +89,18 @@ span.age {
position: relative;
float: left;
width: 142px;
- font-style:italic;
+ font-style: italic;
+}
+
+div.page_body span.signoff {
+ color: #888888;
}
div.log_link {
padding: 0px 8px;
font-size: 10px;
font-family: sans-serif;
- font-style:normal;
+ font-style: normal;
position: relative;
float: left;
width: 136px;
@@ -138,6 +142,14 @@ table {
padding: 8px 4px;
}
+table.project_list, table.diff_tree {
+ border-spacing: 0;
+}
+
+table.blame {
+ border-collapse: collapse;
+}
+
th {
padding: 2px 5px;
font-size: 12px;
@@ -156,11 +168,10 @@ tr.dark:hover {
background-color: #edece6;
}
-
td {
padding: 2px 5px;
font-size: 12px;
- vertical-align:top;
+ vertical-align: top;
}
td.link {
@@ -169,10 +180,77 @@ td.link {
font-size: 10px;
}
-div.pre {
+td.sha1 {
+ font-family: monospace;
+}
+
+td.error {
+ color: red;
+ background-color: yellow;
+}
+
+table.diff_tree span.file_status.new {
+ color: #008000;
+}
+
+table.diff_tree span.file_status.deleted {
+ color: #c00000;
+}
+
+table.diff_tree span.file_status.moved,
+table.diff_tree span.file_status.mode_chnge {
+ color: #777777;
+}
+
+/* age2: 60*60*24*2 <= age */
+table.project_list td.age2, table.blame td.age2 {
+ font-style: italic;
+}
+
+/* age1: 60*60*2 <= age < 60*60*24*2 */
+table.project_list td.age1 {
+ color: #009900;
+ font-style: italic;
+}
+
+table.blame td.age1 {
+ color: #009900;
+ background: transparent;
+}
+
+/* age0: age < 60*60*2 */
+table.project_list td.age0 {
+ color: #009900;
+ font-style: italic;
+ font-weight: bold;
+}
+
+table.blame td.age0 {
+ color: #009900;
+ background: transparent;
+ font-weight: bold;
+}
+
+td.pre, div.pre, div.diff {
font-family: monospace;
font-size: 12px;
white-space: pre;
+}
+
+td.mode {
+ font-family: monospace;
+}
+
+div.diff.add {
+ color: #008800;
+}
+
+div.diff.rem {
+ color: #cc0000;
+}
+
+div.diff.chunk_header {
+ color: #990099;
}
div.diff_info {
@@ -196,6 +273,10 @@ div.search {
right: 12px
}
+td.linenr {
+ text-align: right;
+}
+
a.linenr {
color: #999999;
text-decoration: none
@@ -229,3 +310,11 @@ span.tag {
border: 1px solid;
border-color: #ffffcc #ffee00 #ffee00 #ffffcc;
}
+
+span.atnight {
+ color: #cc0000;
+}
+
+span.match {
+ color: #e00000;
+}
--
1.3.0
^ permalink raw reply related
* Re: packs and trees
From: Nicolas Pitre @ 2006-06-20 15:03 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jon Smirl, git
In-Reply-To: <46a038f90606192313l16b16132r1523f5e05ae1566a@mail.gmail.com>
On Tue, 20 Jun 2006, Martin Langhoff wrote:
> On 6/20/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> > The plan is to modify rcs2git from parsecvs to create all of the git
> > objects for the tree.
>
> Sounds like a good plan. Have you seen recent discussions about it
> being impossible to repack usefully when you don't have trees (and
> resulting performance problems on ext3).
What do you mean?
Nicolas
^ permalink raw reply
* Re: packs and trees
From: Keith Packard @ 2006-06-20 15:18 UTC (permalink / raw)
To: Jon Smirl; +Cc: keithp, Martin Langhoff, git
In-Reply-To: <9e4733910606200735u5741a9adr83264ae7d51dd37@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
On Tue, 2006-06-20 at 10:35 -0400, Jon Smirl wrote:
> Keith's parsecvs run ended up in a loop and mine hit a parsecvs error
> and then had memory corruption after about eight hours. That was last
> week, I just checked the logs and I don't see any comments about
> fixing it.
Yeah, I'm rewriting the tool; the current codebase isn't supportable.
> Even after spending eight hours building the changeset info iit is
> still going to take it a couple of days to retrieve the versions one
> at a time and write them to git. Reparsing 50MB delta files n^2/2
> times is a major bottleneck for all three programs.
The eight hours in question *were* writing out the deltas and packing
the resulting trees. All that remained was to construct actual commit
objects and write them out.
The problem was that parsecvs's internals are structured so that this
processes would take a large amount of memory, so I'm reworking the code
to free stuff as it goes along.
With a rewritten parsecvs, I'm hoping to be able to steal the algorithms
from cvs2svn and stick those in place. Then work on truncating the
history so it can deal with incremental updates to the repository, which
I think will be straightforward if we stick a few breadcrumbs in the git
repository to recover state from.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: David Woodhouse @ 2006-06-20 15:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vd5d4chmg.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-06-20 at 02:15 -0700, Junio C Hamano wrote:
> I wonder if there is somebody who is willing to run gitweb from
> the "next" branch on some public site, so that I can be
> reasonably confident before breaking one of the most important
> infrastructure of the kernel development? Volunteers?
Yeah, we can do it on git.infradead.org if you promise to respond
quickly when you break it. Or I can set up a virtual host on
http://git2.infradead.org/ to use the testing version if you'd prefer.
Mail me a SSH public key, I'll give you an account.
--
dwmw2
^ permalink raw reply
* [PATCH] Add git version to gitweb output
From: Jakub Narebski @ 2006-06-20 15:59 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
---
gitweb/gitweb.cgi | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
09a68749cb29e1f0add3ac9859c11cd0924f70c7
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 89224e6..87ec565 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -29,6 +29,14 @@ my $projectroot = "/home/kay/public_html
# location of the git-core binaries
my $gitbin = "/usr/bin";
+# version of the git-core binaries
+my $git_version = qx($gitbin/git --version);
+if ($git_version =~ m/git version (.*)$/) {
+ $git_version = $1;
+} else {
+ $git_version = "unknown";
+}
+
# location for temporary files needed for diffs
my $git_temp = "/tmp/gitweb";
@@ -288,11 +296,12 @@ sub git_header_html {
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
+<!-- git core binaries version $git_version -->
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
-<link rel="stylesheet" type="text/css" href="$stylesheet"/>
<title>$title</title>
+<link rel="stylesheet" type="text/css" href="$stylesheet"/>
$rss_link
</head>
<body>
@@ -816,7 +825,7 @@ sub git_get_project_config {
$key =~ s/^gitweb\.//;
return if ($key =~ m/\W/);
- my $val = qx(git-repo-config --get gitweb.$key);
+ my $val = qx($gitbin/git-repo-config --get gitweb.$key);
return ($val);
}
--
1.3.0
^ permalink raw reply related
* git grep in .
From: Uwe Zeisberger @ 2006-06-20 16:08 UTC (permalink / raw)
To: git
Hello,
git grep behaves wrongly if I give it . as path to search in.
E.g.
uzeisberger@io:~/gsrc/git$ git version
git version 1.4.0
uzeisberger@io:~/gsrc/git$ git grep git-grep
.gitignore:git-grep
Documentation/git-grep.txt:git-grep(1)
Documentation/git-grep.txt:git-grep - Print lines matching a pattern
Documentation/git-grep.txt:'git-grep' [--cached]
Documentation/git.txt:gitlink:git-grep[1]::
Makefile: git-grep$X git-add$X git-rm$X git-rev-list$X \
builtin-grep.c:"git-grep <option>* <rev>* [-e] <pattern> [<path>...]";
uzeisberger@io:~/gsrc/git$ git grep git-grep .
uzeisberger@io:~/gsrc/git$
I'd expect that `git grep git-grep .` gives the same results as `git
grep git-grep`.
Best regards
Uwe
--
Uwe Zeisberger
exit vi, lesson II:
: w q ! <CR>
NB: write the current file
^ permalink raw reply
* Re: [Q] what to do when waitpid() returns ECHILD under signal(SIGCHLD, SIG_IGN)?
From: Edgar Toernig @ 2006-06-20 16:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtbc7ll6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Somebody I met last week in Japan reported that the socks client
> he uses to cross the firewall to connect to git:// port from his
> company environment seems to do signal(SIGCHLD, SIG_IGN) before
> spawning git.
Similar problems occasionally happen with SIGPIPE. There are apps[1]
that spawn processes with SIGPIPE set to SIG_IGN giving unexpected
results, i.e. child processes that still try to produce output
(getting EPIPE on every printf, but who checks printf errors?) even
if the pipe-reader (e.g. their parent) is long gone.
Ciao, ET.
[1] i.e. KDE had this bug - don't know if it's still there.
^ permalink raw reply
* Re: packs and trees
From: Jon Smirl @ 2006-06-20 16:33 UTC (permalink / raw)
To: Keith Packard; +Cc: Martin Langhoff, git
In-Reply-To: <1150816728.5382.27.camel@neko.keithp.com>
On 6/20/06, Keith Packard <keithp@keithp.com> wrote:
> > Even after spending eight hours building the changeset info iit is
> > still going to take it a couple of days to retrieve the versions one
> > at a time and write them to git. Reparsing 50MB delta files n^2/2
> > times is a major bottleneck for all three programs.
>
> The eight hours in question *were* writing out the deltas and packing
> the resulting trees. All that remained was to construct actual commit
> objects and write them out.
>
> The problem was that parsecvs's internals are structured so that this
> processes would take a large amount of memory, so I'm reworking the code
> to free stuff as it goes along.
How about writing out all of the revisions from the cvs file using the
yacc code the first time the file is encountered and parsed. Then you
only have to track git IDs and not all of those cumbersome CVS rev
numbers. When I was profiling parsecvs the hottest parts of the code
were extracting the revisions and comparing cvs rev numbers. Since the
git IDs are fixed size they work well in arrays and with pointer
compares for sorting. With the right data structure you should be able
to eliminate the CVS rev numbers that are so slow to deal with.
There are about 1M revisions in moz cvs. At eight byes for an ID and
eight bytes for a timestamp that is 16MB if ordering is achieved via
arrays. All of the symbols fit into 400K including pointers to their
revision. If the revs are written out as they are encountered there is
no need to save file names, but you do need one rev structure per
file. Throw in some more memory for relationship pointers. All of this
should fit into less than 100MB RAM.
>
> With a rewritten parsecvs, I'm hoping to be able to steal the algorithms
> from cvs2svn and stick those in place. Then work on truncating the
> history so it can deal with incremental updates to the repository, which
> I think will be straightforward if we stick a few breadcrumbs in the git
> repository to recover state from.
>
> --
> keith.packard@intel.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQBEmBHYQp8BWwlsTdMRAvKAAJ9im3xBdUowt9af+/MtoYDXsCHGtACaAtG4
> GygX7WgiFOamLrnTMzWkIPE=
> =28dp
> -----END PGP SIGNATURE-----
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-20 16:51 UTC (permalink / raw)
To: git
I am planning on copying features from xmms2's gitweb version
to git's gitweb, and introducing new ones.
My gitweb can be seen at http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi
Fetch from http://front.fuw.edu.pl/jnareb/scm/git.git/ (not checked!)
* HTML cleanup - ongoing process of replacing embedded style information
with CSS styling, adding classes and ids to elements. This is independent
on other changes. On top of 'next', as it needs style in separate CSS
file gitweb.css.
* Storing site-wide gitweb configuration in separate gitweb.conf file.
Needs GIT_CONFIG patch. Not implemented yet.
Bootstrapping: gitweb would need location of configuration file.
Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
git in PATH is needed to be able to run git-repo-config to read config;
the solution might be home-grown "parser" to find gitexecdir only.
Both could be set from Makefile at install stage.
* Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
base_url, which need not to be set as there is sane default: use base
of gitweb URL.
Is it useful to allow repository configuration to override it?
* Support for categories from gitweb-xmms2. We can alternatively use
directory structure of git projects displayed by gitweb as categories.
Needs I think some site-wide configuration.
Question: where store categories? .git/category, like .git/description?
Use gitweb.category key? If yes, do convert description to repository key,
or perhaps use gitweb.descriptionfile? What should be priority of those
options if both are set: use repo-config for short (in project listing
and in page footer), and from file for long description on project page?
What if they don't match?
* Refactor dispatch from if...elsif...else construction
to using 'name' => \&sub hash.
* Refactor generation of navigation bar. There are at least two
implementations of that. With hash dispatch it would be easy to
list all possibilities.
* Add (of course optional, like blame support) snapshot support. There are
at least two different implementations. I'd prefer to do without second
CGI script, but perhaps this is better from the performance point of view.
gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
* Code highlighting for plain view for blobs. gitweb-xmms2 did that using
GNU highlight program and some embedded configuration (filename regexp to
syntax used). More generic: run some post-processing. Configurable
globally (perhaps separate "syntax type" filename or file magic mapping),
and enabled per repository (default off).
* gitweb-xmms2 has something called committags support: it means that
'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
sha1-ids into references. Probably needs some extra configuration file,
and some per repository configuration. Of course we want to support not
only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
for marking bugs therein.
* gitweb-xmms2 has also etags based anchors to mark function definitions
in blob view. I'm not sure it would be that usefull. LXR equivalent,
perhaps...
Which of those should be implemented first?
Any further ideas for other useful features?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Carl Worth @ 2006-06-20 17:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]
On Tue, 20 Jun 2006 18:51:18 +0200, Jakub Narebski wrote:
>
> Any further ideas for other useful features?
>
Since you asked...
From the first time I saw gitweb the feature I wanted was to put
more useful information in the path of the URL rather than in the
query string.
One possible organization might be:
/<project>/<commitish>/<path>[/<more_path> ...]
I'd really like to be able to publish nice clean URLs (without any
query component) for getting at particular branches within projects,
for example.
The above might not be entirely feasible in the face of hierachical
project names containing '/' characters as they might then conflict
with branch names.
Another general feature I'd like is for URLs to be as interchangeable
as possible between gitweb and command-line git tools. My goal is to
be able to push out a new branch and then send an email announcing the
branch with a single URL something like:
http://git.somewhere.org/project/branch
where this would obviously work if fed to a web browser, but ideally
would also be possible to feed to git-fetch or even git-clone perhaps
without requiring any user knowledge on how to mangle it first.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-20 17:46 UTC (permalink / raw)
To: git
In-Reply-To: <87r71jspeo.wl%cworth@cworth.org>
Carl Worth wrote:
> On Tue, 20 Jun 2006 18:51:18 +0200, Jakub Narebski wrote:
>>
>> Any further ideas for other useful features?
>>
>
> Since you asked...
>
> From the first time I saw gitweb the feature I wanted was to put
> more useful information in the path of the URL rather than in the
> query string.
>
> One possible organization might be:
>
> /<project>/<commitish>/<path>[/<more_path> ...]
>
> I'd really like to be able to publish nice clean URLs (without any
> query component) for getting at particular branches within projects,
> for example.
>
> The above might not be entirely feasible in the face of hierachical
> project names containing '/' characters as they might then conflict
> with branch names.
And in the face of topic branches with names like 'js/lsfix' or
'gitweb/config'.
Add to that the fact that above needs some support from web server
(e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
to be server agnostic...
One of the part of HTML cleanup would be changing order of URL query string,
so that the human readable part is first.
P.S. I have forgot about:
* Check how gitweb.cgi behaves with mod_perl, and correct/add modifications
to support this mode better (and perhaps also FastCGI if it adds
anything).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2006-06-20 17:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79c8t$8sd$1@sea.gmane.org>
Dear diary, on Tue, Jun 20, 2006 at 07:46:11PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Add to that the fact that above needs some support from web server
> (e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
> to be server agnostic...
Nope, you get the stuff in $PATH_INFO. And having at least just the
project name in the path part would be quite nice, it's my common gripe
with cvsweb as I frequently get to mangle with the query part manually
(can be much faster than clicking around) and I have to carefully evade
the project name part, which is something I would really expect to be in
the "static" part of the URL.
When we are talking about URLs, it would be quite nice if the query
parameter names would be actually meaningful instead of some cryptic
'h', 'pg' and whatnot.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-20 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060620175505.GR2609@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Jun 20, 2006 at 07:46:11PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Add to that the fact that above needs some support from web server
>> (e.g. Apache's mod_rewrite) and web server configuration, while gitweb tries
>> to be server agnostic...
>
> Nope, you get the stuff in $PATH_INFO. And having at least just the
> project name in the path part would be quite nice, it's my common gripe
> with cvsweb as I frequently get to mangle with the query part manually
> (can be much faster than clicking around) and I have to carefully evade
> the project name part, which is something I would really expect to be in
> the "static" part of the URL.
But without web server support I think you would need one copy/symbolic link
per repository served.
> When we are talking about URLs, it would be quite nice if the query
> parameter names would be actually meaningful instead of some cryptic
> 'h', 'pg' and whatnot.
I guess that is because hash values are somewhat long (40 characters wide),
so one letter parameter names were chosen to shorten URL.
Dictionary:
'a' - action (e.g. summary, log, commitdiff, blob, tree)
'o' - order by (for sorting tables)
'p' - project (might include category/directory: cogito/cogito.git,
git/git.git, git/gitk.git)
'f' - filename (I plan to move it before hash-valued parameters,
perhaps except hb which usually is symbolic)
'pg' - page
's' - searchtext (shouldn't it be 'q', from querystring?)
'h' - hash
'hp' - hash parent (not used yet I think)
'hb' - hash base (i.e. head or tag; underused I think)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Petr Baudis @ 2006-06-20 18:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79f3p$jcc$1@sea.gmane.org>
Dear diary, on Tue, Jun 20, 2006 at 08:34:38PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > Nope, you get the stuff in $PATH_INFO. And having at least just the
> > project name in the path part would be quite nice, it's my common gripe
> > with cvsweb as I frequently get to mangle with the query part manually
> > (can be much faster than clicking around) and I have to carefully evade
> > the project name part, which is something I would really expect to be in
> > the "static" part of the URL.
>
> But without web server support I think you would need one copy/symbolic link
> per repository served.
Nope. As I said, the webserver stops in the path at the point it hits
the CGI and the rest is in $PATH_INFO.
> > When we are talking about URLs, it would be quite nice if the query
> > parameter names would be actually meaningful instead of some cryptic
> > 'h', 'pg' and whatnot.
>
> I guess that is because hash values are somewhat long (40 characters wide),
> so one letter parameter names were chosen to shorten URL.
I might argue that since the hash values are so long, few extra bytes
for having the names make some sense aren't going to hurt.
Thanks for the dictionary, though. :)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Martin Langhoff @ 2006-06-20 19:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
On 6/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> I am planning on copying features from xmms2's gitweb version
> to git's gitweb, and introducing new ones.
Cool!
> * Storing site-wide gitweb configuration in separate gitweb.conf file.
> Needs GIT_CONFIG patch. Not implemented yet.
>
> Bootstrapping: gitweb would need location of configuration file.
> Has to be changed in gitweb.cgi itself. Additionally gitexecdir or
> git in PATH is needed to be able to run git-repo-config to read config;
> the solution might be home-grown "parser" to find gitexecdir only.
>
> Both could be set from Makefile at install stage.
There's been some discussion about reading GIT_CONFIG from %ENV (but
defaulting to the repo config). If GIT_CONFIG is set, I think we can
trick git-repo-config to parse it for us.
Now, I suspect we'll want to read _both_ the per-repo config and
GIT_CONFIG, which is likely to be /etc/gitweb.conf or similar.
> * Add git fetch URL to the project page from gitweb-xmms2. Needs site-wide
> base_url, which need not to be set as there is sane default: use base
> of gitweb URL.
>
> Is it useful to allow repository configuration to override it?
I think so, as mentioned above.
> * Add (of course optional, like blame support) snapshot support. There are
> at least two different implementations. I'd prefer to do without second
> CGI script, but perhaps this is better from the performance point of view.
> gitweb-xmms2 has snapshot.cgi in Python: should it be rewritten in Perl?
I intend to post a patch that adds snapshot support in Perl, in the
main code. Just need to make it optional ;-)
> * Code highlighting for plain view for blobs. gitweb-xmms2 did that using
> GNU highlight program and some embedded configuration (filename regexp to
> syntax used). More generic: run some post-processing. Configurable
> globally (perhaps separate "syntax type" filename or file magic mapping),
> and enabled per repository (default off).
Yep, probably a generic filter facility is better...
> * gitweb-xmms2 has something called committags support: it means that
> 'BUG(n)', 'FEATURE(n)' and 'RELEASE: xx' in commit message are turned into
> bugtracker (Mantis for xmms2) or wiki links. It is extension of turning
> sha1-ids into references. Probably needs some extra configuration file,
> and some per repository configuration. Of course we want to support not
> only Mantis, but also e.g. Bugzilla (e.g. Linux kernel) and conventions
> for marking bugs therein.
That would be great.
...
> Which of those should be implemented first?
I like the order the list has... but it's up to you.
> Any further ideas for other useful features?
Now what I think would rock too is something similar to gitk's "nearby
tags" feature. When reading a commit, it lists the heads and tags that
this commit is part of. It's very useful. Now I'll have to read up on
how gitk does it.
And, as you mention in your other post, mod_perl support. And a bit of
speed. Gitweb rght now is really really slow.
cheers,
martin
^ 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