* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Jakub Narebski @ 2006-06-20 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5d4chmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Doesn't work well with values outside us-ascii, but that might be
>> considered web browser bug (misfeature), not a bug in gitweb.
>
> That's sad.
>
> Are you sure about it?
Now I see I was wrong.
> What does start_td({-title=>"blah"}) produce? <td title="blah">?
> If so, is http://members.cox.net/junkio/t.html close to what you
> are trying to achieve here?
Yes, that is what I tried to achieve. Using CGI to set attributes
was to quote characters which cannot be in double quited attribute values,
i.e. change '"' to '"' or '"'. I don't know what start_td did with
\"o character (Perl v5.8.6, CGI::VERSION=3.05).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Timo Hirvonen @ 2006-06-20 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jnareb, git
In-Reply-To: <7vd5d4chmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> 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?
I can help.
http://onion.dynserv.net/git/gitweb.cgi
Note: http://onion.dynserv.net/git/ (index.cgi) is an old version.
Global symbol "$path" requires explicit package name at
/var/www/localhost/htdocs/git/gitweb.cgi line 1521.
Execution of /var/www/localhost/htdocs/git/gitweb.cgi aborted due to
compilation errors.
The line is:
$file =~ m#^/# or $file = "$projectroot/$path/$file";
$path seems to be undefined. I don't understand perl very well so I
can't fix it.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Junio C Hamano @ 2006-06-20 9:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <4497B39E.2050205@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> Here's a real world example of the 1.4.0 change breaking a merge:
>
> ("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
> [jgarzik@pretzel netdev-2.6]$ git branch
> ALL
> e100-sbit
> * master
> upstream
> upstream-linus
>
> [jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
> ...
> Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
> 25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
> fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile'
> would be overwritten by merge.
>
> EXPLANATION:
>
> * drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
> stored locally in /spare/repo/linux-2.6.
> * drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
> netdev-2.6#upstream-linus branches.
> * drivers/net/myri10ge/Makefile does not exist in current branch,
> netdev-2.6#master.
Requesting one more bit of explanation.
When you did this pull, you were on your "master" branch. Whose
HEAD does not have the myri10ge/Makefile in its tree. And you
did not have that path in the index either (otherwise it would
not have said "untracked working tree file"). Did you have that
file in your working tree? And if so how/why?
If you did something like this before ending up in your "master"
branch, I think you would have such a file:
$ git branch ;# you were in upstream-linus branch
ALL
e100-sbit
master
upstream
* upstream-linus
$ git diff ;# and were up-to-date -- no output nor
$ git diff HEAD ;# local changes
$ git checkout -f master ;# but you switched to master with -f
With "checkout -f", your local changes to files that appear in
the "master" branch will be overwritten, but the files that are
supposed to disappear because you are switching out of the
current branch (e.g. myri10ge/Makefile) are left behind.
It probably would make sense to change "checkout -f" so that it
removes such files from your working tree to support this
particular usage. We kept saying "with -f local dirty state
will be gone", but "checkout -f" does not do as thorough job as
"reset --hard". Changing "checkout -f next-branch" to do the
moral equivalent of "reset --hard HEAD && checkout next-branch"
would solve this problem, and I do not think changing it that
way would not have any negative impact.
I suspect this patch would do exactly that...
diff --git a/git-checkout.sh b/git-checkout.sh
index 564117f..193f6c5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -137,7 +137,7 @@ # what we already had
if [ "$force" ]
then
- git-read-tree --reset $new &&
+ git-read-tree --reset -u $new &&
git-checkout-index -q -f -u -a
else
git-update-index --refresh >/dev/null
^ permalink raw reply related
* Re: git 1.4.0 usability problem
From: Ryan Anderson @ 2006-06-20 9:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Junio C Hamano, git
In-Reply-To: <4497B39E.2050205@garzik.org>
On Tue, Jun 20, 2006 at 04:36:46AM -0400, Jeff Garzik wrote:
> Here's a real world example of the 1.4.0 change breaking a merge:
>
> ("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
> [jgarzik@pretzel netdev-2.6]$ git branch
> ALL
> e100-sbit
> * master
> upstream
> upstream-linus
>
> [jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
> Generating pack...
> Done counting 3427 objects.
> Result has 2510 objects.
> Deltifying 2510 objects.
> 100% (2510/2510) done
> Unpacking 2510 objects
> Total 2510, written 2510 (delta 2024), reused 0 (delta 0)
> 100% (2510/2510) done
> Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
> 25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
> fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile' would
> be overwritten by merge.
>
> EXPLANATION:
>
> * drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
> stored locally in /spare/repo/linux-2.6.
> * drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
> netdev-2.6#upstream-linus branches.
> * drivers/net/myri10ge/Makefile does not exist in current branch,
> netdev-2.6#master.
If that is the case, how did it get into the directory, then?
I suspect the history we're missing is this:
git checkout upstream
...
git checkout -f master
If you have a clean tree, there's not really a reason to use -f. It
actively hurts you by confusing git as to what state your directory is
in. (If you don't have a clean tree, well, using -f will orphan new
files that Git knows about, and overwrite the changes on ones it does,
so it's still rather inconsistent, and probably not at all what you
intend.)
Instead of using "git checkout -f" to abandon any WIP, try something
like this:
git branch throw-away HEAD
git checkout throw-away
git commit -a -m "throw away"
git checkout $1
git branch -D throw-away
i.e:
$ sed -i -e 's/PHONY/YNOHP/g' Makefile
$ git branch throw-away HEAD
$ git checkout throw-away
$ git diff |diffstat
Makefile | 60 ++++++++++++++++++++++++++++++------------------------------
$ git commit -a -m "throw-away"
$ git checkout master
$ git branch -d throw-away
The branch 'throw-away' is not a strict subset of your current HEAD.
If you are sure you want to delete it, run 'git branch -D throw-away'.
$ git branch -D throw-away
Deleted branch throw-away.
$ git diff | diffstat
0 files changed
$ git branch throw-away HEAD
$ cp Makefile Makefile-ryan
$ git add Makefile-ryan
$ git checkout throw-away
$ git diff | diffstat
0 files changed
$ git status
# On branch refs/heads/throw-away
#
# Updated but not checked in:
# (will commit)
#
# new file: Makefile-ryan
#
$ git commit -a -m "throw-away"
$ git checkout master
$ git status
nothing to commit
Note that using plain "checkout" should be noticeably faster, too.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Junio C Hamano @ 2006-06-20 9:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200606201012.31684.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Doesn't work well with values outside us-ascii, but that might be
> considered web browser bug (misfeature), not a bug in gitweb.
That's sad.
Are you sure about it?
What does start_td({-title=>"blah"}) produce? <td title="blah">?
If so, is http://members.cox.net/junkio/t.html close to what you
are trying to achieve here?
> "<td>$pr->{'descr'}</td>\n" .
> - "<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
> + $cgi->start_td({-title => $pr->{'owner'}}) . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
Where did the opening <i> go? Not that I care about italics,
since I think this should all be done with stylesheet, but I do
care about unbalanced pairs.
BTW, I haven't nailed down the procedure to update the
kernel.org gitweb installations (I suspect the burden is on me
since Kay orphaned gitweb onto me).
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?
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Junio C Hamano @ 2006-06-20 8:58 UTC (permalink / raw)
To: Rene Scharfe; +Cc: git
In-Reply-To: <4497AED4.5060505@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> BTW, I think we would probably want to have this patch on top of
>> Rene's patch. In all instances, the variable "buf" is of type
>> "const char *" and the existing casts do not make sense to me.
>>
>> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
>> index 5c8a5f0..39a61b6 100644
>
> Your patch reverts builtin-tar-tree.c to the version which is
> currently both in master and next, which I think is a good
> change. However, could it be avoided at merge time?
Sorry for attributing those "casts [that] do not make sense to
me" to you -- it is not your code but part of Florian's patch.
I think applying the patch in question on top of Florian's 11172e
would be the most sensible, since that is currently the tip of ff/c99
topic branch whose early parts have been merged to "next" and
the tip to "pu". When Linus feels as sympathetic as I do, we
can pull the rest of ff/c99 branch to "next" and then eventually
to "master" and the patch will be merged together without
introducing the nonsense casts.
Another possibility is to amend the tip of ff/c99 topic branch,
since it is not merged to "next" yet. I promised not to rewind
"master" nor "next", but never made promises not to rewind "pu",
so it is a fair game. I think it is simpler and cleaner, so
that will be what I will do.
> OT: I found the blobs 5c8a5f0 and 39a61b6 by guessing (they are
> builtin-tar-tree.c in pu and master, respectively). OK, that
> was easy. But is there a way to reversely look up an object
> without guessing, i.e. find out which commit(s) introduced a
> certain blob?
You could do something like this (totally untested).
Going from the above "diff --git" index line you have object
name abbreviations and pathnames as clues. To take advantage of
it, you could use "git rev-list pu -- builtin-tar-tree.c"
instead of unlimited list.
$ git rev-list pu |
git diff-tree -r --stdin --pretty |
perl -e '
my @lines = ();
sub flush_em {
my @found = ();
my @comment = ();
for my $l (@lines) {
if ($l !~ /^:/) {
push @comment, $l;
next;
}
for (@ARGV) {
if ($l =~ / $_/) {
push @found, $l;
last;
}
}
}
if (@found) {
print join("", @comment, @found);
}
@lines = ();
}
while (<STDIN>) {
if (/^commit [0-9a-f]{40}$/) { flush_em(); }
push @lines, $_;
}
flush_em();
' 39a61b6 5c8a5f0
^ permalink raw reply
* Re: git 1.4.0 usability problem
From: Jeff Garzik @ 2006-06-20 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pyhdel5.fsf@assigned-by-dhcp.cox.net>
Here's a real world example of the 1.4.0 change breaking a merge:
("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
[jgarzik@pretzel netdev-2.6]$ git branch
ALL
e100-sbit
* master
upstream
upstream-linus
[jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
Generating pack...
Done counting 3427 objects.
Result has 2510 objects.
Deltifying 2510 objects.
100% (2510/2510) done
Unpacking 2510 objects
Total 2510, written 2510 (delta 2024), reused 0 (delta 0)
100% (2510/2510) done
Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile' would
be overwritten by merge.
EXPLANATION:
* drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
stored locally in /spare/repo/linux-2.6.
* drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
netdev-2.6#upstream-linus branches.
* drivers/net/myri10ge/Makefile does not exist in current branch,
netdev-2.6#master.
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Rene Scharfe @ 2006-06-20 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Florian Forster, git, Linus Torvalds
In-Reply-To: <7vac8860z9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> BTW, I think we would probably want to have this patch on top of
> Rene's patch. In all instances, the variable "buf" is of type
> "const char *" and the existing casts do not make sense to me.
>
>
> diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
> index 5c8a5f0..39a61b6 100644
Your patch reverts builtin-tar-tree.c to the version which is
currently both in master and next, which I think is a good
change. However, could it be avoided at merge time?
OT: I found the blobs 5c8a5f0 and 39a61b6 by guessing (they are
builtin-tar-tree.c in pu and master, respectively). OK, that
was easy. But is there a way to reversely look up an object
without guessing, i.e. find out which commit(s) introduced a
certain blob?
Thanks,
René
^ permalink raw reply
* [PATCH/RFC] gitweb: Add title attribute with unshortened value for table cells
From: Jakub Narebski @ 2006-06-20 8:12 UTC (permalink / raw)
To: git
This allows to see full, unshortened value on mouseover using 'title'
attribute for <td> element. For now it means only author name and
project owner name.
Ugly solution using $cgi->start_td({-title => VALUE})
Doesn't work well with values outside us-ascii, but that might be
considered web browser bug (misfeature), not a bug in gitweb.
---
The idea is to have full value available on mouseover, be it commit title,
author of the commit, project owner, tag name/title or project description.
For now only author name and project owner name are implemented, and
implementation is ugly and results is not perfect.
gitweb/gitweb.cgi | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
b72280ac4649d54375732de771f7d92c7d350258
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 1b254df..9a09b20 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -887,7 +887,7 @@ sub git_project_list {
$alternate ^= 1;
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";
+ $cgi->start_td({-title => $pr->{'owner'}}) . 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>";
@@ -1057,7 +1057,7 @@ sub git_summary {
$ref = " <span class=\"tag\">" . esc_html($refs->{$commit}) . "</span>";
}
print "<td><i>$co{'age_string'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ $cgi->start_td({-title => $co{'author_name'}}) . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
"<td>";
if (length($co{'title_short'}) < length($co{'title'})) {
print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
@@ -2306,7 +2306,7 @@ sub git_history {
}
$alternate ^= 1;
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ $cgi->start_td({-title => $co{'author_name'}}) . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
"<td>" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list"}, "<b>" .
esc_html(chop_str($co{'title'}, 50)) . "$ref</b>") . "</td>\n" .
"<td class=\"link\">" .
@@ -2396,7 +2396,7 @@ sub git_search {
}
$alternate ^= 1;
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ $cgi->start_td({-title => $co{'author_name'}}) . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
"<td>" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$co{'id'}"), -class => "list"}, "<b>" . esc_html(chop_str($co{'title'}, 50)) . "</b><br/>");
my $comment = $co{'comment'};
@@ -2449,7 +2449,7 @@ sub git_search {
}
$alternate ^= 1;
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ $cgi->start_td({-title => $co{'author_name'}}) . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
"<td>" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$co{'id'}"), -class => "list"}, "<b>" .
esc_html(chop_str($co{'title'}, 50)) . "</b><br/>");
@@ -2537,7 +2537,7 @@ sub git_shortlog {
}
$alternate ^= 1;
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ $cgi->start_td({-title => $co{'author_name'}}) . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
"<td>";
if (length($co{'title_short'}) < length($co{'title'})) {
print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
--
1.3.0
^ permalink raw reply related
* Apologies for the 2 late-night bugs
From: Johannes Schindelin @ 2006-06-20 7:54 UTC (permalink / raw)
To: git
Hi,
with the recent patches to introduce $HOME/.gitconfig, I also introduced
two bugs. They were not due to lacking of testing, but rather due to
testing with an accidentally set GIT_CONFIG. And now I *know* why I did
not want that thing in the first place. And I decided not to become a
pilot, ever.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git_config: access() returns 0 on success, not > 0
From: Johannes Schindelin @ 2006-06-20 7:51 UTC (permalink / raw)
To: git, junkio
Another late-night bug. Sorry again.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.c b/config.c
index d064f42..3e077d4 100644
--- a/config.c
+++ b/config.c
@@ -335,7 +335,7 @@ int git_config(config_fn_t fn)
if (home) {
char *user_config = strdup(mkpath("%s/.gitconfig", home));
- if (access(user_config, R_OK) > 0)
+ if (!access(user_config, R_OK))
ret = git_config_from_file(fn, user_config);
free(user_config);
}
--
1.4.0.g59268-dirty
^ permalink raw reply related
* [PATCH] repo-config: Fix late-night bug
From: Johannes Schindelin @ 2006-06-20 7:45 UTC (permalink / raw)
To: git, junkio
This bug was hidden by the "future-proofing" of the test. Sigh.
When neither GIT_CONFIG nor GIT_CONFIG_LOCAL is set, do not use NULL,
but $GIT_DIR/config. Instead of using $GIT_DIR/config when only
GIT_CONFIG_LOCAL is set. Sorry.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This time, "only" repo-config was affected, _not_ all users of
the config file.
repo-config.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/repo-config.c b/repo-config.c
index 03f108f..ab8f1af 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -74,8 +74,6 @@ static int get_value(const char* key_, c
const char *home = getenv("HOME");
local = getenv("GIT_CONFIG_LOCAL");
if (!local)
- local = repo_config;
- else
local = repo_config = strdup(git_path("config"));
if (home)
global = strdup(mkpath("%s/.gitconfig", home));
--
1.4.0.g59268-dirty
^ permalink raw reply related
* Re: wrong check condition in patch-delta.c?
From: Marco Roeland @ 2006-06-20 7:21 UTC (permalink / raw)
To: Nguy???n Thái Ng???c Duy; +Cc: git
In-Reply-To: <fcaeb9bf0606192332j5b2ee4b9ycf2c63c7b1820204@mail.gmail.com>
On Tuesday June 20th 2006 Nguy???n Thái Ng???c Duy wrote:
> 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?
It protects against possible overflow. Adding fixed length integers is
"wraparound" after all and discards the "carry" bit.
--
Marco Roeland
^ permalink raw reply
* wrong check condition in patch-delta.c?
From: Nguyễn Thái Ngọc Duy @ 2006-06-20 6:32 UTC (permalink / raw)
To: git
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?
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: add '/' to the end of filename in page title for trees
From: Jakub Narebski @ 2006-06-20 6:22 UTC (permalink / raw)
To: git
In-Reply-To: <1150784206793-git-send-email-jnareb@gmail.com>
This should of course be [PATCH 2/2]. I'm sorry for mistake.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Fix: Support for the standard mime.types map in gitweb
From: Jakub Narebski @ 2006-06-20 6:19 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Temporary fix: commented out offending line in mimetype_guess.
---
gitweb/gitweb.cgi | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
718a3b4c1e56c0330fa2c7ced2e66be5b095b541
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 11cc71f..1b254df 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1524,7 +1524,7 @@ sub mimetype_guess {
if ($mimetypes_file) {
my $file = $mimetypes_file;
- $file =~ m#^/# or $file = "$projectroot/$path/$file";
+ #$file =~ m#^/# or $file = "$projectroot/$path/$file";
$mime = mimetype_guess_file($filename, $file);
}
$mime ||= mimetype_guess_file($filename, '/etc/mime.types');
--
1.3.0
^ permalink raw reply related
* [PATCH 1/2] gitweb: add '/' to the end of filename in page title for trees
From: Jakub Narebski @ 2006-06-20 6:17 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11507842053885-git-send-email-jnareb@gmail.com>
---
gitweb/gitweb.cgi | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
d17c119d32ae4c5dd50976ea6a255d2bcbe480ed
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 1e1a044..42f3296 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -263,6 +263,9 @@ sub git_header_html {
$title .= "/$action";
if (defined $file_name) {
$title .= " - $file_name";
+ if ($action eq "tree" && $file_name !~ m|/$|) {
+ $title .= "/";
+ }
}
}
}
--
1.3.0
^ permalink raw reply related
* [PATCH 0/2] gitweb: Enhance page title
From: Jakub Narebski @ 2006-06-20 6:17 UTC (permalink / raw)
To: git
This series of patches adds filename (with '/' at the end added for
trees, i.e. directories) to the page title, for easier bookmarking and
viewing browser history.
On top of 'next', but should apply cleanly for 'master' too.
^ permalink raw reply
* [PATCH 1/2] gitweb: Add filename to page title if set
From: Jakub Narebski @ 2006-06-20 6:17 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11507842053885-git-send-email-jnareb@gmail.com>
---
gitweb/gitweb.cgi | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
a54751bb328072baed5446bdc4076f1e00002737
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 12d5271..1e1a044 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -260,7 +260,10 @@ sub git_header_html {
if (defined $project) {
$title .= " - $project";
if (defined $action) {
+ if (defined $file_name) {
+ $title .= " - $file_name";
+ }
}
}
print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
--
1.3.0
^ permalink raw reply related
* Re: packs and trees
From: Martin Langhoff @ 2006-06-20 6:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606192257y1516e966t848a3b1e29e5667f@mail.gmail.com>
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).
> 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 ;-)
> 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.
cheers,
martin
^ permalink raw reply
* packs and trees
From: Jon Smirl @ 2006-06-20 5:57 UTC (permalink / raw)
To: git
Converting from CVS would be a lot more efficient if all of revisions
contained in a CVS file were written into git at the same time. So, if
I extract complete revisions from 100 source files into git objects
and then ask git to incremental pack, will git find all of the deltas
and do a good job packing? Some of these files have thousands (50MB)
of deltas. Also, note that I have not written any tree info into git
yet.
After all of the revisions are into git, I will follow up with the
tree info and then repack all. How will the pack end up grouped,
chronologically or will it still be sorted by file? It is not clear to
me how the tree info interacts with the magic packing sauce.
The plan is to modify rcs2git from parsecvs to create all of the git
objects for the tree. It would be called by the cvs2svn code which
would track the object IDs through the changeset generation process.
At the end it will write all of the trees connecting the objects
together.
cvs2svn seems to do a good job at generating the trees. I am not
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.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH (fixed)] git-svn: fix --rmdir when using SVN:: libraries
From: Eric Wong @ 2006-06-20 5:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqso7him.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Makefile: automatically run new tests as they appear in t/
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > ---
> >
> > Oops, I left out the Makefile change in the other patch,...
>
> Yeah, I was wondering about that.
>
> > ... had the new
> > test file as +x
>
> Shouldn't they be executable? It is not a big deal, because you
> run them via $(SHELL), though...
Yes, I prefer to use $(SHELL) instead. Makes it easier to test with
different shells without mucking /bin/sh
--
Eric Wong
^ permalink raw reply
* [PATCH] gitweb: add type="text/css" to stylesheet link
From: Jakub Narebski @ 2006-06-20 4:11 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
---
gitweb/gitweb.cgi | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
75b6977d185f946fcab8b86011f37869948c1dac
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index fa90c51..c582424 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -39,7 +39,7 @@ # html text to include at home page
my $home_text = "indextext.html";
# URI of default stylesheet
-my $stylesheet = "gitweb.css";
+my $stylesheet = "gitweb.css";
# source of projects list
#my $projects_list = $projectroot;
@@ -272,7 +272,7 @@ sub git_header_html {
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
-<link rel="stylesheet" href="$stylesheet"/>
+<link rel="stylesheet" type="text/css" href="$stylesheet"/>
<title>$title</title>
$rss_link
</head>
--
1.3.0
^ permalink raw reply related
* [PATCH] Make CSS file gitweb/gitweb.css more readable
From: Jakub Narebski @ 2006-06-20 3:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <7vwtbc9a45.fsf@assigned-by-dhcp.cox.net>
---
gitweb/gitweb.css | 273 +++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 223 insertions(+), 50 deletions(-)
72888c0a080d95117d54dc9578dc2a0de7b19abd
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 5900916..9d91426 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,58 +1,231 @@
body {
- font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
- margin:10px; background-color:#ffffff; color:#000000;
-}
-a { color:#0000cc; }
-a:hover, a:visited, a:active { color:#880000; }
-div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
-div.page_header a:visited, a.header { color:#0000cc; }
-div.page_header a:hover { color:#880000; }
-div.page_nav { padding:8px; }
-div.page_nav a:visited { color:#0000cc; }
-div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
-div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
-div.page_footer_text { float:left; color:#555555; font-style:italic; }
-div.page_body { padding:8px; }
+ font-family: sans-serif;
+ font-size: 12px;
+ border:solid #d9d8d1;
+ border-width: 1px;
+ margin: 10px;
+ background-color: #ffffff;
+ color: #000000;
+}
+
+a {
+ color: #0000cc;
+}
+
+a:hover, a:visited, a:active {
+ color: #880000;
+}
+
+div.page_header {
+ height: 25px;
+ padding: 8px;
+ font-size: 18px;
+ font-weight: bold;
+ background-color: #d9d8d1;
+}
+
+div.page_header a:visited, a.header {
+ color: #0000cc;
+}
+
+div.page_header a:hover {
+ color: #880000;
+}
+
+div.page_nav {
+ padding:8px;
+}
+
+div.page_nav a:visited {
+ color: #0000cc;
+}
+
+div.page_path {
+ padding: 8px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
+}
+
+div.page_footer {
+ height: 17px;
+ padding: 4px 8px;
+ background-color: #d9d8d1;
+}
+
+div.page_footer_text {
+ float: left;
+ color: #555555;
+ font-style: italic;
+}
+
+div.page_body {
+ padding: 8px;
+}
+
div.title, a.title {
- display:block; padding:6px 8px;
- font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
+ display: block;
+ padding: 6px 8px;
+ font-weight: bold;
+ background-color: #edece6;
+ text-decoration: none;
+ color: #000000;
+}
+
+a.title:hover {
+ background-color: #d9d8d1;
+}
+
+div.title_text {
+ padding: 6px 0px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
}
-a.title:hover { background-color: #d9d8d1; }
-div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
-div.log_body { padding:8px 8px 8px 150px; }
-span.age { position:relative; float:left; width:142px; font-style:italic; }
+
+div.log_body {
+ padding: 8px 8px 8px 150px;
+}
+
+span.age {
+ position: relative;
+ float: left;
+ width: 142px;
+ font-style:italic;
+}
+
div.log_link {
- padding:0px 8px;
- font-size:10px; font-family:sans-serif; font-style:normal;
- position:relative; float:left; width:136px;
-}
-div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
-a.list { text-decoration:none; color:#000000; }
-a.list:hover { text-decoration:underline; color:#880000; }
-a.text { text-decoration:none; color:#0000cc; }
-a.text:visited { text-decoration:none; color:#880000; }
-a.text:hover { text-decoration:underline; color:#880000; }
-table { padding:8px 4px; }
-th { padding:2px 5px; font-size:12px; text-align:left; }
-tr.light:hover { background-color:#edece6; }
-tr.dark { background-color:#f6f6f0; }
-tr.dark:hover { background-color:#edece6; }
-td { padding:2px 5px; font-size:12px; vertical-align:top; }
-td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
-div.pre { font-family:monospace; font-size:12px; white-space:pre; }
-div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
-div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
-div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
-a.linenr { color:#999999; text-decoration:none }
+ padding: 0px 8px;
+ font-size: 10px;
+ font-family: sans-serif;
+ font-style:normal;
+ position: relative;
+ float: left;
+ width: 136px;
+}
+
+div.list_head {
+ padding: 6px 8px 4px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 0px;
+ font-style: italic;
+}
+
+a.list {
+ text-decoration: none;
+ color: #000000;
+}
+
+a.list:hover {
+ text-decoration: underline;
+ color: #880000;
+}
+
+a.text {
+ text-decoration: none;
+ color: #0000cc;
+}
+
+a.text:visited {
+ text-decoration: none;
+ color: #880000;
+}
+
+a.text:hover {
+ text-decoration: underline;
+ color: #880000;
+}
+
+table {
+ padding: 8px 4px;
+}
+
+th {
+ padding: 2px 5px;
+ font-size: 12px;
+ text-align: left;
+}
+
+tr.light:hover {
+ background-color: #edece6;
+}
+
+tr.dark {
+ background-color: #f6f6f0;
+}
+
+tr.dark:hover {
+ background-color: #edece6;
+}
+
+
+td {
+ padding: 2px 5px;
+ font-size: 12px;
+ vertical-align:top;
+}
+
+td.link {
+ padding: 2px 5px;
+ font-family: sans-serif;
+ font-size: 10px;
+}
+
+div.pre {
+ font-family: monospace;
+ font-size: 12px;
+ white-space: pre;
+ /* padding-left: 5px; */
+}
+
+div.diff_info {
+ font-family: monospace;
+ color: #000099;
+ background-color: #edece6;
+ font-style: italic;
+}
+
+div.index_include {
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
+ padding: 12px 8px;
+}
+
+div.search {
+ margin: 4px 8px;
+ position: absolute;
+ top: 56px;
+ right: 12px
+}
+
+a.linenr {
+ color: #999999;
+ text-decoration: none
+}
+
a.rss_logo {
- float:right; padding:3px 0px; width:35px; line-height:10px;
- border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
- color:#ffffff; background-color:#ff6600;
- font-weight:bold; font-family:sans-serif; font-size:10px;
- text-align:center; text-decoration:none;
+ float: right;
+ padding: 3px 0px;
+ width: 35px;
+ line-height: 10px;
+ border: 1px solid;
+ border-color: #fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color: #ffffff;
+ background-color: #ff6600;
+ font-weight: bold;
+ font-family: sans-serif;
+ font-size: 10px;
+ text-align: center;
+ text-decoration: none;
+}
+
+a.rss_logo:hover {
+ background-color: #ee5500;
}
-a.rss_logo:hover { background-color:#ee5500; }
+
span.tag {
- padding:0px 4px; font-size:10px; font-weight:normal;
- background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
+ padding: 0px 4px;
+ font-size: 10px;
+ font-weight: normal;
+ background-color: #ffffaa;
+ border: 1px solid;
+ border-color: #ffffcc #ffee00 #ffee00 #ffffcc;
}
--
1.3.0
^ permalink raw reply related
* Re: [PATCH] Make CSS file gitweb/gitweb.css more readable
From: Jakub Narebski @ 2006-06-20 3:32 UTC (permalink / raw)
To: git
In-Reply-To: <e77prc$v40$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> Jakub, I've been applying your patches after hand-fixing but it
>> appears that there is serious whitespace breakage on the mail
>> path somewhere between you and the mailing list. Please check
>> your MUA.
>
> Checking:
It looks like KNode/0.7.7 (from KDE 3.2.2) converts tabs to spaces
even for inserted files.
I'll use email client (KMail or git-send-email) in the future.
I'll be resending the patch as part of larger series in near future.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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