2005-08-07 19:49:46 +02:00
|
|
|
#!/usr/bin/perl
|
|
|
|
|
2005-08-07 20:27:18 +02:00
|
|
|
# gitweb - simple web interface to track changes in git repositories
|
2005-08-07 19:56:59 +02:00
|
|
|
#
|
2005-08-07 19:49:46 +02:00
|
|
|
# (C) 2005, Kay Sievers <kay.sievers@vrfy.org>
|
|
|
|
# (C) 2005, Christian Gierke <ch@gierke.de>
|
2005-08-07 19:57:58 +02:00
|
|
|
#
|
2005-10-04 01:12:47 +02:00
|
|
|
# This program is licensed under the GPLv2
|
2005-08-07 19:49:46 +02:00
|
|
|
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
2005-08-07 20:26:27 +02:00
|
|
|
use CGI qw(:standard :escapeHTML -nosticky);
|
2005-08-07 20:23:49 +02:00
|
|
|
use CGI::Util qw(unescape);
|
2005-08-07 19:49:46 +02:00
|
|
|
use CGI::Carp qw(fatalsToBrowser);
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
use Encode;
|
2005-08-07 20:21:04 +02:00
|
|
|
use Fcntl ':mode';
|
2005-11-23 04:26:40 +01:00
|
|
|
binmode STDOUT, ':utf8';
|
2005-08-07 19:49:46 +02:00
|
|
|
|
2005-08-07 20:05:15 +02:00
|
|
|
my $cgi = new CGI;
|
2005-11-23 04:26:40 +01:00
|
|
|
my $version = "253";
|
2005-08-07 20:21:04 +02:00
|
|
|
my $my_url = $cgi->url();
|
|
|
|
my $my_uri = $cgi->url(-absolute => 1);
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $rss_link = "";
|
2005-08-07 20:05:15 +02:00
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
# absolute fs-path which will be prepended to the project path
|
2005-08-31 03:25:29 +02:00
|
|
|
#my $projectroot = "/pub/scm";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $projectroot = "/home/kay/public_html/pub/scm";
|
2005-08-07 20:21:04 +02:00
|
|
|
|
|
|
|
# location of the git-core binaries
|
2005-08-07 20:17:09 +02:00
|
|
|
my $gitbin = "/usr/bin";
|
2005-08-07 20:21:04 +02:00
|
|
|
|
|
|
|
# location for temporary files needed for diffs
|
2005-08-07 20:26:27 +02:00
|
|
|
my $git_temp = "/tmp/gitweb";
|
2005-08-07 20:20:07 +02:00
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
# target of the home link on top of all pages
|
2005-08-07 20:23:12 +02:00
|
|
|
my $home_link = $my_uri;
|
2005-08-07 20:21:04 +02:00
|
|
|
|
2005-08-07 20:22:53 +02:00
|
|
|
# html text to include at home page
|
|
|
|
my $home_text = "indextext.html";
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
# source of projects list
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
#my $projects_list = $projectroot;
|
|
|
|
my $projects_list = "index/index.aux";
|
2005-08-07 20:21:04 +02:00
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
# input validation and dispatch
|
|
|
|
my $action = $cgi->param('a');
|
|
|
|
if (defined $action) {
|
2005-09-03 14:50:33 +02:00
|
|
|
if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
|
2005-08-07 20:21:23 +02:00
|
|
|
undef $action;
|
|
|
|
die_error(undef, "Invalid action parameter.");
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
if ($action eq "git-logo.png") {
|
|
|
|
git_logo();
|
|
|
|
exit;
|
2005-08-07 20:27:18 +02:00
|
|
|
} elsif ($action eq "opml") {
|
|
|
|
git_opml();
|
|
|
|
exit;
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 19:59:24 +02:00
|
|
|
|
2005-08-10 03:53:09 +02:00
|
|
|
my $order = $cgi->param('o');
|
|
|
|
if (defined $order) {
|
2005-09-03 14:50:33 +02:00
|
|
|
if ($order =~ m/[^0-9a-zA-Z_]/) {
|
2005-08-10 03:53:09 +02:00
|
|
|
undef $order;
|
|
|
|
die_error(undef, "Invalid order parameter.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:06:09 +02:00
|
|
|
my $project = $cgi->param('p');
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $project) {
|
2005-09-03 14:50:33 +02:00
|
|
|
$project = validate_input($project);
|
|
|
|
if (!defined($project)) {
|
|
|
|
die_error(undef, "Invalid project parameter.");
|
2005-08-07 20:17:42 +02:00
|
|
|
}
|
|
|
|
if (!(-d "$projectroot/$project")) {
|
2005-08-07 20:21:04 +02:00
|
|
|
undef $project;
|
2005-08-07 20:21:23 +02:00
|
|
|
die_error(undef, "No such directory.");
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
|
|
|
if (!(-e "$projectroot/$project/HEAD")) {
|
|
|
|
undef $project;
|
2005-08-07 20:21:23 +02:00
|
|
|
die_error(undef, "No such project.");
|
2005-08-07 20:17:42 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$rss_link = "<link rel=\"alternate\" title=\"" . esc_url($project) . " log\" href=\"" .
|
|
|
|
esc_url("$my_uri?p=$project;a=rss") . "\" type=\"application/rss+xml\"/>";
|
2005-08-07 20:27:38 +02:00
|
|
|
$ENV{'GIT_DIR'} = "$projectroot/$project";
|
2005-08-07 20:21:23 +02:00
|
|
|
} else {
|
2005-08-07 20:23:12 +02:00
|
|
|
git_project_list();
|
2005-08-07 20:21:23 +02:00
|
|
|
exit;
|
2005-08-07 20:15:44 +02:00
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
|
|
|
|
my $file_name = $cgi->param('f');
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $file_name) {
|
2005-09-03 14:50:33 +02:00
|
|
|
$file_name = validate_input($file_name);
|
|
|
|
if (!defined($file_name)) {
|
|
|
|
die_error(undef, "Invalid file parameter.");
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:15:44 +02:00
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
|
|
|
|
my $hash = $cgi->param('h');
|
2005-08-07 20:27:38 +02:00
|
|
|
if (defined $hash) {
|
2005-09-03 14:50:33 +02:00
|
|
|
$hash = validate_input($hash);
|
|
|
|
if (!defined($hash)) {
|
|
|
|
die_error(undef, "Invalid hash parameter.");
|
2005-08-07 20:27:38 +02:00
|
|
|
}
|
2005-08-07 20:15:44 +02:00
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
|
|
|
|
my $hash_parent = $cgi->param('hp');
|
2005-09-03 14:50:33 +02:00
|
|
|
if (defined $hash_parent) {
|
|
|
|
$hash_parent = validate_input($hash_parent);
|
|
|
|
if (!defined($hash_parent)) {
|
|
|
|
die_error(undef, "Invalid hash parent parameter.");
|
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
my $hash_base = $cgi->param('hb');
|
2005-09-03 14:50:33 +02:00
|
|
|
if (defined $hash_base) {
|
|
|
|
$hash_base = validate_input($hash_base);
|
|
|
|
if (!defined($hash_base)) {
|
|
|
|
die_error(undef, "Invalid hash base parameter.");
|
|
|
|
}
|
2005-08-07 20:15:44 +02:00
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
|
2005-08-07 20:26:49 +02:00
|
|
|
my $page = $cgi->param('pg');
|
|
|
|
if (defined $page) {
|
2005-09-03 14:50:33 +02:00
|
|
|
if ($page =~ m/[^0-9]$/) {
|
2005-08-07 20:26:49 +02:00
|
|
|
undef $page;
|
|
|
|
die_error(undef, "Invalid page parameter.");
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:14:48 +02:00
|
|
|
}
|
2005-08-07 19:57:58 +02:00
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
my $searchtext = $cgi->param('s');
|
|
|
|
if (defined $searchtext) {
|
|
|
|
if ($searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
|
|
|
|
undef $searchtext;
|
|
|
|
die_error(undef, "Invalid search parameter.");
|
|
|
|
}
|
|
|
|
$searchtext = quotemeta $searchtext;
|
|
|
|
}
|
|
|
|
|
2005-09-03 14:50:33 +02:00
|
|
|
sub validate_input {
|
|
|
|
my $input = shift;
|
|
|
|
|
|
|
|
if ($input =~ m/^[0-9a-fA-F]{40}$/) {
|
|
|
|
return $input;
|
|
|
|
}
|
|
|
|
if ($input =~ m/(^|\/)(|\.|\.\.)($|\/)/) {
|
|
|
|
return undef;
|
|
|
|
}
|
2005-11-14 06:10:07 +01:00
|
|
|
if ($input =~ m/[^a-zA-Z0-9_ \.\/\-\+\#\~]/) {
|
2005-09-03 14:50:33 +02:00
|
|
|
return undef;
|
|
|
|
}
|
|
|
|
return $input;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:27:38 +02:00
|
|
|
if (!defined $action || $action eq "summary") {
|
2005-08-07 20:23:12 +02:00
|
|
|
git_summary();
|
|
|
|
exit;
|
2005-10-04 01:12:47 +02:00
|
|
|
} elsif ($action eq "heads") {
|
|
|
|
git_heads();
|
2005-08-07 20:24:35 +02:00
|
|
|
exit;
|
2005-08-07 20:23:12 +02:00
|
|
|
} elsif ($action eq "tags") {
|
|
|
|
git_tags();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "blob") {
|
2005-08-07 20:21:23 +02:00
|
|
|
git_blob();
|
|
|
|
exit;
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($action eq "blob_plain") {
|
|
|
|
git_blob_plain();
|
|
|
|
exit;
|
2005-08-07 20:21:23 +02:00
|
|
|
} elsif ($action eq "tree") {
|
|
|
|
git_tree();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "rss") {
|
|
|
|
git_rss();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "commit") {
|
|
|
|
git_commit();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "log") {
|
|
|
|
git_log();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "blobdiff") {
|
|
|
|
git_blobdiff();
|
|
|
|
exit;
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($action eq "blobdiff_plain") {
|
|
|
|
git_blobdiff_plain();
|
|
|
|
exit;
|
2005-08-07 20:21:23 +02:00
|
|
|
} elsif ($action eq "commitdiff") {
|
|
|
|
git_commitdiff();
|
|
|
|
exit;
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($action eq "commitdiff_plain") {
|
|
|
|
git_commitdiff_plain();
|
|
|
|
exit;
|
2005-08-07 20:21:23 +02:00
|
|
|
} elsif ($action eq "history") {
|
|
|
|
git_history();
|
|
|
|
exit;
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($action eq "search") {
|
|
|
|
git_search();
|
|
|
|
exit;
|
|
|
|
} elsif ($action eq "shortlog") {
|
|
|
|
git_shortlog();
|
|
|
|
exit;
|
2005-08-07 20:28:53 +02:00
|
|
|
} elsif ($action eq "tag") {
|
|
|
|
git_tag();
|
|
|
|
exit;
|
2005-08-07 20:21:23 +02:00
|
|
|
} else {
|
|
|
|
undef $action;
|
|
|
|
die_error(undef, "Unknown action.");
|
|
|
|
exit;
|
|
|
|
}
|
|
|
|
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
sub esc_url {
|
2005-11-14 05:47:18 +01:00
|
|
|
my $str = shift;
|
2005-11-14 06:10:07 +01:00
|
|
|
$str =~ s/\+/%2B/g;
|
2005-11-14 15:15:12 +01:00
|
|
|
$str =~ s/ /\+/g;
|
2005-11-14 05:47:18 +01:00
|
|
|
return $str;
|
|
|
|
}
|
|
|
|
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
sub esc_html {
|
|
|
|
my $str = shift;
|
|
|
|
$str = decode("utf8", $str, Encode::FB_DEFAULT);
|
2005-11-23 04:26:40 +01:00
|
|
|
$str = escapeHTML($str);
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
return $str;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:02:47 +02:00
|
|
|
sub git_header_html {
|
2005-08-07 20:15:44 +02:00
|
|
|
my $status = shift || "200 OK";
|
2005-10-19 03:18:45 +02:00
|
|
|
my $expires = shift;
|
2005-08-07 20:15:44 +02:00
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
my $title = "git";
|
|
|
|
if (defined $project) {
|
|
|
|
$title .= " - $project";
|
|
|
|
if (defined $action) {
|
|
|
|
$title .= "/$action";
|
|
|
|
}
|
|
|
|
}
|
2005-10-19 03:18:45 +02:00
|
|
|
print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
|
2005-08-07 20:15:44 +02:00
|
|
|
print <<EOF;
|
2005-08-07 20:19:56 +02:00
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
2005-08-07 19:49:46 +02:00
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
2005-08-07 20:20:07 +02:00
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
|
2005-08-07 20:19:56 +02:00
|
|
|
<!-- git web interface v$version, (C) 2005, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke <ch\@gierke.de> -->
|
2005-08-07 19:49:46 +02:00
|
|
|
<head>
|
2005-08-07 20:27:18 +02:00
|
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
|
|
|
|
<meta name="robots" content="index, nofollow"/>
|
2005-08-07 20:21:04 +02:00
|
|
|
<title>$title</title>
|
2005-08-07 20:19:56 +02:00
|
|
|
$rss_link
|
|
|
|
<style type="text/css">
|
2005-08-07 20:22:44 +02:00
|
|
|
body { font-family: sans-serif; font-size: 12px; margin:0px; border:solid #d9d8d1; border-width:1px; margin:10px; }
|
2005-08-07 20:19:56 +02:00
|
|
|
a { color:#0000cc; }
|
2005-08-07 20:22:44 +02:00
|
|
|
a:hover, a:visited, a:active { color:#880000; }
|
|
|
|
div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
|
2005-08-12 21:43:32 +02:00
|
|
|
div.page_header a:visited, a.header { color:#0000cc; }
|
2005-08-07 20:19:56 +02:00
|
|
|
div.page_header a:hover { color:#880000; }
|
2005-08-07 20:22:44 +02:00
|
|
|
div.page_nav { padding:8px; }
|
2005-08-07 20:19:56 +02:00
|
|
|
div.page_nav a:visited { color:#0000cc; }
|
2005-08-07 20:26:27 +02:00
|
|
|
div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
|
2005-08-07 20:22:44 +02:00
|
|
|
div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
|
2005-08-07 20:19:56 +02:00
|
|
|
div.page_footer_text { float:left; color:#555555; font-style:italic; }
|
2005-08-07 20:22:44 +02:00
|
|
|
div.page_body { padding:8px; }
|
2005-08-07 20:19:56 +02:00
|
|
|
div.title, a.title {
|
2005-08-07 20:22:44 +02:00
|
|
|
display:block; padding:6px 8px;
|
2005-08-07 20:19:56 +02:00
|
|
|
font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
|
|
|
|
}
|
|
|
|
a.title:hover { background-color: #d9d8d1; }
|
2005-08-07 20:25:42 +02:00
|
|
|
div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
|
2005-08-07 20:22:44 +02:00
|
|
|
div.log_body { padding:8px 8px 8px 150px; }
|
2005-08-07 20:24:01 +02:00
|
|
|
span.age { position:relative; float:left; width:142px; font-style:italic; }
|
2005-08-07 20:22:44 +02:00
|
|
|
div.log_link {
|
2005-08-07 20:25:42 +02:00
|
|
|
padding:0px 8px;
|
2005-08-07 20:22:44 +02:00
|
|
|
font-size:10px; font-family:sans-serif; font-style:normal;
|
2005-08-07 20:25:42 +02:00
|
|
|
position:relative; float:left; width:136px;
|
2005-08-07 20:19:56 +02:00
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
|
2005-08-07 20:25:27 +02:00
|
|
|
a.list { text-decoration:none; color:#000000; }
|
2005-08-07 20:27:18 +02:00
|
|
|
a.list:hover { text-decoration:underline; color:#880000; }
|
2005-08-07 20:28:53 +02:00
|
|
|
a.text { text-decoration:none; color:#0000cc; }
|
|
|
|
a.text:visited { text-decoration:none; color:#880000; }
|
|
|
|
a.text:hover { text-decoration:underline; color:#880000; }
|
2005-08-07 20:25:42 +02:00
|
|
|
table { padding:8px 4px; }
|
|
|
|
th { padding:2px 5px; font-size:12px; text-align:left; }
|
2005-08-07 20:27:18 +02:00
|
|
|
tr.light:hover { background-color:#edece6; }
|
|
|
|
tr.dark { background-color:#f6f6f0; }
|
|
|
|
tr.dark:hover { background-color:#edece6; }
|
2005-08-07 20:26:27 +02:00
|
|
|
td { padding:2px 5px; font-size:12px; vertical-align:top; }
|
2005-08-07 20:25:42 +02:00
|
|
|
td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
|
2005-08-07 20:22:44 +02:00
|
|
|
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; }
|
2005-08-07 20:22:53 +02:00
|
|
|
div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
|
2005-08-07 20:27:18 +02:00
|
|
|
div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
|
2005-08-07 20:27:27 +02:00
|
|
|
a.linenr { color:#999999; text-decoration:none }
|
2005-08-07 20:27:18 +02:00
|
|
|
a.rss_logo {
|
|
|
|
float:right; padding:3px 0px; width:35px; line-height:10px;
|
2005-08-07 20:21:23 +02:00
|
|
|
border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
|
2005-08-07 20:19:56 +02:00
|
|
|
color:#ffffff; background-color:#ff6600;
|
2005-08-07 20:21:23 +02:00
|
|
|
font-weight:bold; font-family:sans-serif; font-size:10px;
|
|
|
|
text-align:center; text-decoration:none;
|
2005-08-07 20:19:56 +02:00
|
|
|
}
|
2005-08-07 20:20:20 +02:00
|
|
|
a.rss_logo:hover { background-color:#ee5500; }
|
2005-08-07 20:19:56 +02:00
|
|
|
</style>
|
2005-08-07 19:49:46 +02:00
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
EOF
|
2005-08-07 20:13:02 +02:00
|
|
|
print "<div class=\"page_header\">\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<a href=\"http://www.kernel.org/pub/software/scm/git/docs/\" title=\"git documentation\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<img src=\"" . esc_url("$my_uri?a=git-logo.png") . "\" width=\"72\" height=\"27\" alt=\"git\" style=\"float:right; border-width:0px;\"/>" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</a>\n";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url($home_link)}, "projects") . " / ";
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $project) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, esc_html($project));
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $action) {
|
|
|
|
print " / $action";
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
print "\n";
|
|
|
|
if (!defined $searchtext) {
|
|
|
|
$searchtext = "";
|
|
|
|
}
|
2005-09-17 03:00:21 +02:00
|
|
|
my $search_hash;
|
|
|
|
if (defined $hash) {
|
|
|
|
$search_hash = $hash;
|
|
|
|
} else {
|
|
|
|
$search_hash = "HEAD";
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
$cgi->param("a", "search");
|
2005-09-17 03:00:21 +02:00
|
|
|
$cgi->param("h", $search_hash);
|
2005-11-14 05:47:18 +01:00
|
|
|
print $cgi->startform(-method => "get", -action => $my_uri) .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<div class=\"search\">\n" .
|
|
|
|
$cgi->hidden(-name => "p") . "\n" .
|
|
|
|
$cgi->hidden(-name => "a") . "\n" .
|
2005-09-17 03:00:21 +02:00
|
|
|
$cgi->hidden(-name => "h") . "\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
|
|
|
|
"</div>" .
|
|
|
|
$cgi->end_form() . "\n";
|
2005-08-07 19:52:52 +02:00
|
|
|
}
|
|
|
|
print "</div>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:02:47 +02:00
|
|
|
sub git_footer_html {
|
2005-08-07 20:19:56 +02:00
|
|
|
print "<div class=\"page_footer\">\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $project) {
|
2005-08-07 20:21:23 +02:00
|
|
|
my $descr = git_read_description($project);
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $descr) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<div class=\"page_footer_text\">" . esc_html($descr) . "</div>\n";
|
2005-08-07 20:19:56 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=rss"), -class => "rss_logo"}, "RSS") . "\n";
|
2005-08-07 20:27:18 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?a=opml"), -class => "rss_logo"}, "OPML") . "\n";
|
2005-08-07 20:13:02 +02:00
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
print "</div>\n" .
|
|
|
|
"</body>\n" .
|
2005-08-07 20:17:42 +02:00
|
|
|
"</html>";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:15:57 +02:00
|
|
|
sub die_error {
|
|
|
|
my $status = shift || "403 Forbidden";
|
2005-08-07 20:15:44 +02:00
|
|
|
my $error = shift || "Malformed query, file missing or permission denied";
|
2005-08-07 20:17:19 +02:00
|
|
|
|
2005-08-07 20:15:44 +02:00
|
|
|
git_header_html($status);
|
|
|
|
print "<div class=\"page_body\">\n" .
|
2005-08-07 20:25:54 +02:00
|
|
|
"<br/><br/>\n" .
|
|
|
|
"$status - $error\n" .
|
|
|
|
"<br/>\n" .
|
|
|
|
"</div>\n";
|
2005-08-07 20:15:44 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
exit;
|
2005-08-07 20:15:44 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:46 +02:00
|
|
|
sub git_get_type {
|
|
|
|
my $hash = shift;
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file -t $hash" or return;
|
2005-08-07 20:21:46 +02:00
|
|
|
my $type = <$fd>;
|
2005-08-07 20:28:53 +02:00
|
|
|
close $fd or return;
|
2005-08-07 20:21:46 +02:00
|
|
|
chomp $type;
|
|
|
|
return $type;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:23:12 +02:00
|
|
|
sub git_read_hash {
|
2005-08-07 20:08:03 +02:00
|
|
|
my $path = shift;
|
2005-08-07 20:21:23 +02:00
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "$projectroot/$path" or return undef;
|
2005-08-07 20:02:47 +02:00
|
|
|
my $head = <$fd>;
|
|
|
|
close $fd;
|
|
|
|
chomp $head;
|
2005-08-07 20:21:04 +02:00
|
|
|
if ($head =~ m/^[0-9a-fA-F]{40}$/) {
|
|
|
|
return $head;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_read_description {
|
2005-08-07 20:21:04 +02:00
|
|
|
my $path = shift;
|
2005-08-07 20:21:23 +02:00
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "$projectroot/$path/description" or return undef;
|
2005-08-07 20:21:04 +02:00
|
|
|
my $descr = <$fd>;
|
|
|
|
close $fd;
|
|
|
|
chomp $descr;
|
|
|
|
return $descr;
|
2005-08-07 20:02:47 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:23:12 +02:00
|
|
|
sub git_read_tag {
|
|
|
|
my $tag_id = shift;
|
|
|
|
my %tag;
|
2005-08-07 20:28:53 +02:00
|
|
|
my @comment;
|
2005-08-07 20:23:12 +02:00
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file tag $tag_id" or return;
|
2005-08-07 20:28:53 +02:00
|
|
|
$tag{'id'} = $tag_id;
|
2005-08-07 20:23:12 +02:00
|
|
|
while (my $line = <$fd>) {
|
|
|
|
chomp $line;
|
|
|
|
if ($line =~ m/^object ([0-9a-fA-F]{40})$/) {
|
|
|
|
$tag{'object'} = $1;
|
2005-08-07 20:25:54 +02:00
|
|
|
} elsif ($line =~ m/^type (.+)$/) {
|
2005-08-07 20:23:12 +02:00
|
|
|
$tag{'type'} = $1;
|
2005-08-07 20:25:54 +02:00
|
|
|
} elsif ($line =~ m/^tag (.+)$/) {
|
2005-08-07 20:23:12 +02:00
|
|
|
$tag{'name'} = $1;
|
2005-08-07 20:28:53 +02:00
|
|
|
} elsif ($line =~ m/^tagger (.*) ([0-9]+) (.*)$/) {
|
|
|
|
$tag{'author'} = $1;
|
|
|
|
$tag{'epoch'} = $2;
|
|
|
|
$tag{'tz'} = $3;
|
|
|
|
} elsif ($line =~ m/--BEGIN/) {
|
|
|
|
push @comment, $line;
|
|
|
|
last;
|
|
|
|
} elsif ($line eq "") {
|
|
|
|
last;
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:28:53 +02:00
|
|
|
push @comment, <$fd>;
|
|
|
|
$tag{'comment'} = \@comment;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or return;
|
2005-08-07 20:23:12 +02:00
|
|
|
if (!defined $tag{'name'}) {
|
|
|
|
return
|
|
|
|
};
|
|
|
|
return %tag
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:29:03 +02:00
|
|
|
sub age_string {
|
|
|
|
my $age = shift;
|
|
|
|
my $age_str;
|
|
|
|
|
|
|
|
if ($age > 60*60*24*365*2) {
|
|
|
|
$age_str = (int $age/60/60/24/365);
|
|
|
|
$age_str .= " years ago";
|
|
|
|
} elsif ($age > 60*60*24*(365/12)*2) {
|
|
|
|
$age_str = int $age/60/60/24/(365/12);
|
|
|
|
$age_str .= " months ago";
|
|
|
|
} elsif ($age > 60*60*24*7*2) {
|
|
|
|
$age_str = int $age/60/60/24/7;
|
|
|
|
$age_str .= " weeks ago";
|
|
|
|
} elsif ($age > 60*60*24*2) {
|
|
|
|
$age_str = int $age/60/60/24;
|
|
|
|
$age_str .= " days ago";
|
|
|
|
} elsif ($age > 60*60*2) {
|
|
|
|
$age_str = int $age/60/60;
|
|
|
|
$age_str .= " hours ago";
|
|
|
|
} elsif ($age > 60*2) {
|
|
|
|
$age_str = int $age/60;
|
|
|
|
$age_str .= " min ago";
|
|
|
|
} elsif ($age > 2) {
|
|
|
|
$age_str = int $age;
|
|
|
|
$age_str .= " sec ago";
|
|
|
|
} else {
|
|
|
|
$age_str .= " right now";
|
|
|
|
}
|
|
|
|
return $age_str;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_read_commit {
|
2005-08-07 20:26:27 +02:00
|
|
|
my $commit_id = shift;
|
|
|
|
my $commit_text = shift;
|
|
|
|
|
|
|
|
my @commit_lines;
|
2005-08-07 20:03:14 +02:00
|
|
|
my %co;
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
if (defined $commit_text) {
|
|
|
|
@commit_lines = @$commit_text;
|
|
|
|
} else {
|
2005-09-13 02:21:59 +02:00
|
|
|
$/ = "\0";
|
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list --header --parents --max-count=1 $commit_id" or return;
|
|
|
|
@commit_lines = split '\n', <$fd>;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or return;
|
2005-09-13 02:21:59 +02:00
|
|
|
$/ = "\n";
|
|
|
|
pop @commit_lines;
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
2005-09-13 02:21:59 +02:00
|
|
|
my $header = shift @commit_lines;
|
|
|
|
if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
($co{'id'}, my @parents) = split ' ', $header;
|
|
|
|
$co{'parents'} = \@parents;
|
|
|
|
$co{'parent'} = $parents[0];
|
2005-08-07 20:26:27 +02:00
|
|
|
while (my $line = shift @commit_lines) {
|
2005-08-07 20:21:04 +02:00
|
|
|
last if $line eq "\n";
|
2005-08-07 20:25:54 +02:00
|
|
|
if ($line =~ m/^tree ([0-9a-fA-F]{40})$/) {
|
2005-08-07 20:03:14 +02:00
|
|
|
$co{'tree'} = $1;
|
2005-08-07 20:06:09 +02:00
|
|
|
} elsif ($line =~ m/^author (.*) ([0-9]+) (.*)$/) {
|
2005-08-07 20:03:52 +02:00
|
|
|
$co{'author'} = $1;
|
2005-08-07 20:13:11 +02:00
|
|
|
$co{'author_epoch'} = $2;
|
|
|
|
$co{'author_tz'} = $3;
|
2005-08-07 20:26:03 +02:00
|
|
|
if ($co{'author'} =~ m/^([^<]+) </) {
|
|
|
|
$co{'author_name'} = $1;
|
|
|
|
} else {
|
|
|
|
$co{'author_name'} = $co{'author'};
|
|
|
|
}
|
2005-08-07 20:08:29 +02:00
|
|
|
} elsif ($line =~ m/^committer (.*) ([0-9]+) (.*)$/) {
|
|
|
|
$co{'committer'} = $1;
|
2005-08-07 20:13:11 +02:00
|
|
|
$co{'committer_epoch'} = $2;
|
|
|
|
$co{'committer_tz'} = $3;
|
2005-08-07 20:09:33 +02:00
|
|
|
$co{'committer_name'} = $co{'committer'};
|
|
|
|
$co{'committer_name'} =~ s/ <.*//;
|
2005-08-07 20:03:14 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:23:12 +02:00
|
|
|
if (!defined $co{'tree'}) {
|
2005-09-13 02:21:59 +02:00
|
|
|
return;
|
2005-08-07 20:23:12 +02:00
|
|
|
};
|
2005-09-13 02:21:59 +02:00
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
foreach my $title (@commit_lines) {
|
|
|
|
if ($title ne "") {
|
2005-08-31 03:54:45 +02:00
|
|
|
$co{'title'} = chop_str($title, 80, 5);
|
2005-08-07 20:26:27 +02:00
|
|
|
# remove leading stuff of merges to make the interesting part visible
|
|
|
|
if (length($title) > 50) {
|
|
|
|
$title =~ s/^Automatic //;
|
|
|
|
$title =~ s/^merge (of|with) /Merge ... /i;
|
|
|
|
if (length($title) > 50) {
|
|
|
|
$title =~ s/(http|rsync):\/\///;
|
|
|
|
}
|
|
|
|
if (length($title) > 50) {
|
|
|
|
$title =~ s/(master|www|rsync)\.//;
|
|
|
|
}
|
|
|
|
if (length($title) > 50) {
|
|
|
|
$title =~ s/kernel.org:?//;
|
|
|
|
}
|
|
|
|
if (length($title) > 50) {
|
|
|
|
$title =~ s/\/pub\/scm//;
|
|
|
|
}
|
|
|
|
}
|
2005-08-31 03:54:45 +02:00
|
|
|
$co{'title_short'} = chop_str($title, 50, 5);
|
2005-08-07 20:26:27 +02:00
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
2005-09-13 02:21:59 +02:00
|
|
|
# remove added spaces
|
|
|
|
foreach my $line (@commit_lines) {
|
|
|
|
$line =~ s/^ //;
|
|
|
|
}
|
|
|
|
$co{'comment'} = \@commit_lines;
|
2005-08-07 20:17:00 +02:00
|
|
|
|
|
|
|
my $age = time - $co{'committer_epoch'};
|
|
|
|
$co{'age'} = $age;
|
2005-08-07 20:29:03 +02:00
|
|
|
$co{'age_string'} = age_string($age);
|
2005-08-07 20:27:27 +02:00
|
|
|
my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday) = gmtime($co{'committer_epoch'});
|
|
|
|
if ($age > 60*60*24*7*2) {
|
2005-08-07 20:28:01 +02:00
|
|
|
$co{'age_string_date'} = sprintf "%4i-%02u-%02i", 1900 + $year, $mon+1, $mday;
|
2005-08-07 20:27:27 +02:00
|
|
|
$co{'age_string_age'} = $co{'age_string'};
|
|
|
|
} else {
|
|
|
|
$co{'age_string_date'} = $co{'age_string'};
|
2005-08-07 20:28:01 +02:00
|
|
|
$co{'age_string_age'} = sprintf "%4i-%02u-%02i", 1900 + $year, $mon+1, $mday;
|
2005-08-07 20:27:27 +02:00
|
|
|
}
|
2005-08-07 20:03:14 +02:00
|
|
|
return %co;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
sub git_diff_print {
|
2005-08-07 20:05:44 +02:00
|
|
|
my $from = shift;
|
2005-08-07 20:20:20 +02:00
|
|
|
my $from_name = shift;
|
2005-08-07 20:05:44 +02:00
|
|
|
my $to = shift;
|
2005-08-07 20:20:20 +02:00
|
|
|
my $to_name = shift;
|
2005-08-07 20:26:27 +02:00
|
|
|
my $format = shift || "html";
|
2005-08-07 19:52:52 +02:00
|
|
|
|
2005-08-07 20:05:44 +02:00
|
|
|
my $from_tmp = "/dev/null";
|
|
|
|
my $to_tmp = "/dev/null";
|
|
|
|
my $pid = $$;
|
2005-08-07 19:52:52 +02:00
|
|
|
|
2005-08-07 20:13:02 +02:00
|
|
|
# create tmp from-file
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $from) {
|
2005-08-07 20:26:27 +02:00
|
|
|
$from_tmp = "$git_temp/gitweb_" . $$ . "_from";
|
2005-08-07 20:21:04 +02:00
|
|
|
open my $fd2, "> $from_tmp";
|
2005-08-07 20:20:07 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file blob $from";
|
2005-08-07 20:05:44 +02:00
|
|
|
my @file = <$fd>;
|
|
|
|
print $fd2 @file;
|
2005-08-07 19:52:52 +02:00
|
|
|
close $fd2;
|
|
|
|
close $fd;
|
|
|
|
}
|
|
|
|
|
2005-08-07 19:55:05 +02:00
|
|
|
# create tmp to-file
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $to) {
|
2005-08-07 20:26:27 +02:00
|
|
|
$to_tmp = "$git_temp/gitweb_" . $$ . "_to";
|
2005-08-07 20:05:44 +02:00
|
|
|
open my $fd2, "> $to_tmp";
|
2005-08-07 20:20:07 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file blob $to";
|
2005-08-07 20:05:44 +02:00
|
|
|
my @file = <$fd>;
|
|
|
|
print $fd2 @file;
|
2005-08-07 19:52:52 +02:00
|
|
|
close $fd2;
|
|
|
|
close $fd;
|
|
|
|
}
|
|
|
|
|
2005-11-14 06:10:07 +01:00
|
|
|
open my $fd, "-|", "/usr/bin/diff -u -p -L \'$from_name\' -L \'$to_name\' $from_tmp $to_tmp";
|
2005-08-07 20:26:27 +02:00
|
|
|
if ($format eq "plain") {
|
|
|
|
undef $/;
|
|
|
|
print <$fd>;
|
|
|
|
$/ = "\n";
|
|
|
|
} else {
|
|
|
|
while (my $line = <$fd>) {
|
|
|
|
chomp($line);
|
|
|
|
my $char = substr($line, 0, 1);
|
|
|
|
my $color = "";
|
|
|
|
if ($char eq '+') {
|
|
|
|
$color = " style=\"color:#008800;\"";
|
|
|
|
} elsif ($char eq "-") {
|
|
|
|
$color = " style=\"color:#cc0000;\"";
|
|
|
|
} elsif ($char eq "@") {
|
|
|
|
$color = " style=\"color:#990099;\"";
|
|
|
|
} elsif ($char eq "\\") {
|
|
|
|
# skip errors
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
while ((my $pos = index($line, "\t")) != -1) {
|
|
|
|
if (my $count = (8 - (($pos-1) % 8))) {
|
|
|
|
my $spaces = ' ' x $count;
|
|
|
|
$line =~ s/\t/$spaces/;
|
|
|
|
}
|
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<div class=\"pre\"$color>" . esc_html($line) . "</div>\n";
|
2005-08-07 20:22:44 +02:00
|
|
|
}
|
2005-08-07 19:52:52 +02:00
|
|
|
}
|
|
|
|
close $fd;
|
2005-08-07 20:05:44 +02:00
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $from) {
|
2005-08-07 20:20:20 +02:00
|
|
|
unlink($from_tmp);
|
2005-08-07 20:05:44 +02:00
|
|
|
}
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $to) {
|
2005-08-07 20:20:20 +02:00
|
|
|
unlink($to_tmp);
|
2005-08-07 20:05:44 +02:00
|
|
|
}
|
2005-08-07 19:52:52 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:05:55 +02:00
|
|
|
sub mode_str {
|
2005-08-07 20:20:20 +02:00
|
|
|
my $mode = oct shift;
|
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
if (S_ISDIR($mode & S_IFMT)) {
|
|
|
|
return 'drwxr-xr-x';
|
|
|
|
} elsif (S_ISLNK($mode)) {
|
|
|
|
return 'lrwxrwxrwx';
|
|
|
|
} elsif (S_ISREG($mode)) {
|
2005-08-07 20:09:33 +02:00
|
|
|
# git cares only about the executable bit
|
2005-08-07 20:21:04 +02:00
|
|
|
if ($mode & S_IXUSR) {
|
|
|
|
return '-rwxr-xr-x';
|
2005-08-07 20:08:03 +02:00
|
|
|
} else {
|
2005-08-07 20:21:04 +02:00
|
|
|
return '-rw-r--r--';
|
2005-08-07 20:08:03 +02:00
|
|
|
};
|
2005-08-07 20:21:04 +02:00
|
|
|
} else {
|
|
|
|
return '----------';
|
2005-08-07 20:05:55 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:26:03 +02:00
|
|
|
sub chop_str {
|
|
|
|
my $str = shift;
|
|
|
|
my $len = shift;
|
2005-08-07 20:26:27 +02:00
|
|
|
my $add_len = shift || 10;
|
2005-08-07 20:26:03 +02:00
|
|
|
|
2005-08-31 03:25:29 +02:00
|
|
|
# allow only $len chars, but don't cut a word if it would fit in $add_len
|
|
|
|
# if it doesn't fit, cut it if it's still longer than the dots we would add
|
|
|
|
$str =~ m/^(.{0,$len}[^ \/\-_:\.@]{0,$add_len})(.*)/;
|
|
|
|
my $body = $1;
|
|
|
|
my $tail = $2;
|
|
|
|
if (length($tail) > 4) {
|
|
|
|
$tail = " ...";
|
2005-08-07 20:26:03 +02:00
|
|
|
}
|
2005-08-31 03:25:29 +02:00
|
|
|
return "$body$tail";
|
2005-08-07 20:26:03 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:20:20 +02:00
|
|
|
sub file_type {
|
|
|
|
my $mode = oct shift;
|
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
if (S_ISDIR($mode & S_IFMT)) {
|
2005-08-07 20:20:20 +02:00
|
|
|
return "directory";
|
2005-08-07 20:21:04 +02:00
|
|
|
} elsif (S_ISLNK($mode)) {
|
2005-08-07 20:20:20 +02:00
|
|
|
return "symlink";
|
2005-08-07 20:21:04 +02:00
|
|
|
} elsif (S_ISREG($mode)) {
|
|
|
|
return "file";
|
2005-08-07 20:20:20 +02:00
|
|
|
} else {
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:28:42 +02:00
|
|
|
sub format_log_line_html {
|
|
|
|
my $line = shift;
|
|
|
|
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$line = esc_html($line);
|
2005-08-07 20:28:42 +02:00
|
|
|
$line =~ s/ / /g;
|
|
|
|
if ($line =~ m/([0-9a-fA-F]{40})/) {
|
|
|
|
my $hash_text = $1;
|
|
|
|
if (git_get_type($hash_text) eq "commit") {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $link = $cgi->a({-class => "text", -href => esc_url("$my_uri?p=$project;a=commit;h=$hash_text")}, $hash_text);
|
2005-08-07 20:28:42 +02:00
|
|
|
$line =~ s/$hash_text/$link/;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return $line;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:08:29 +02:00
|
|
|
sub date_str {
|
2005-08-07 20:09:33 +02:00
|
|
|
my $epoch = shift;
|
|
|
|
my $tz = shift || "-0000";
|
2005-08-07 20:08:29 +02:00
|
|
|
|
2005-08-07 20:09:33 +02:00
|
|
|
my %date;
|
2005-08-07 20:08:29 +02:00
|
|
|
my @months = ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec");
|
|
|
|
my @days = ("Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat");
|
2005-08-07 20:09:33 +02:00
|
|
|
my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday) = gmtime($epoch);
|
|
|
|
$date{'hour'} = $hour;
|
2005-08-07 20:13:02 +02:00
|
|
|
$date{'minute'} = $min;
|
|
|
|
$date{'mday'} = $mday;
|
|
|
|
$date{'day'} = $days[$wday];
|
|
|
|
$date{'month'} = $months[$mon];
|
2005-08-07 20:09:33 +02:00
|
|
|
$date{'rfc2822'} = sprintf "%s, %d %s %4d %02d:%02d:%02d +0000", $days[$wday], $mday, $months[$mon], 1900+$year, $hour ,$min, $sec;
|
|
|
|
$date{'mday-time'} = sprintf "%d %s %02d:%02d", $mday, $months[$mon], $hour ,$min;
|
|
|
|
|
2005-08-07 20:20:07 +02:00
|
|
|
$tz =~ m/^([+\-][0-9][0-9])([0-9][0-9])$/;
|
|
|
|
my $local = $epoch + ((int $1 + ($2/60)) * 3600);
|
2005-08-07 20:09:33 +02:00
|
|
|
($sec, $min, $hour, $mday, $mon, $year, $wday, $yday) = gmtime($local);
|
2005-08-07 20:13:11 +02:00
|
|
|
$date{'hour_local'} = $hour;
|
|
|
|
$date{'minute_local'} = $min;
|
|
|
|
$date{'tz_local'} = $tz;
|
2005-08-07 20:09:33 +02:00
|
|
|
return %date;
|
2005-08-07 20:08:29 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:04 +02:00
|
|
|
# git-logo (cached in browser for one day)
|
2005-08-07 20:21:34 +02:00
|
|
|
sub git_logo {
|
2005-11-23 16:02:13 +01:00
|
|
|
binmode STDOUT, ':raw';
|
2005-08-07 20:06:09 +02:00
|
|
|
print $cgi->header(-type => 'image/png', -expires => '+1d');
|
2005-08-07 20:21:04 +02:00
|
|
|
# cat git-logo.png | hexdump -e '16/1 " %02x" "\n"' | sed 's/ /\\x/g'
|
|
|
|
print "\x89\x50\x4e\x47\x0d\x0a\x1a\x0a\x00\x00\x00\x0d\x49\x48\x44\x52" .
|
|
|
|
"\x00\x00\x00\x48\x00\x00\x00\x1b\x04\x03\x00\x00\x00\x2d\xd9\xd4" .
|
|
|
|
"\x2d\x00\x00\x00\x18\x50\x4c\x54\x45\xff\xff\xff\x60\x60\x5d\xb0" .
|
|
|
|
"\xaf\xaa\x00\x80\x00\xce\xcd\xc7\xc0\x00\x00\xe8\xe8\xe6\xf7\xf7" .
|
|
|
|
"\xf6\x95\x0c\xa7\x47\x00\x00\x00\x73\x49\x44\x41\x54\x28\xcf\x63" .
|
|
|
|
"\x48\x67\x20\x04\x4a\x5c\x18\x0a\x08\x2a\x62\x53\x61\x20\x02\x08" .
|
|
|
|
"\x0d\x69\x45\xac\xa1\xa1\x01\x30\x0c\x93\x60\x36\x26\x52\x91\xb1" .
|
|
|
|
"\x01\x11\xd6\xe1\x55\x64\x6c\x6c\xcc\x6c\x6c\x0c\xa2\x0c\x70\x2a" .
|
|
|
|
"\x62\x06\x2a\xc1\x62\x1d\xb3\x01\x02\x53\xa4\x08\xe8\x00\x03\x18" .
|
|
|
|
"\x26\x56\x11\xd4\xe1\x20\x97\x1b\xe0\xb4\x0e\x35\x24\x71\x29\x82" .
|
|
|
|
"\x99\x30\xb8\x93\x0a\x11\xb9\x45\x88\xc1\x8d\xa0\xa2\x44\x21\x06" .
|
|
|
|
"\x27\x41\x82\x40\x85\xc1\x45\x89\x20\x70\x01\x00\xa4\x3d\x21\xc5" .
|
|
|
|
"\x12\x1c\x9a\xfe\x00\x00\x00\x00\x49\x45\x4e\x44\xae\x42\x60\x82";
|
2005-08-07 20:06:09 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:22:44 +02:00
|
|
|
sub get_file_owner {
|
|
|
|
my $path = shift;
|
|
|
|
|
|
|
|
my ($dev, $ino, $mode, $nlink, $st_uid, $st_gid, $rdev, $size) = stat($path);
|
|
|
|
my ($name, $passwd, $uid, $gid, $quota, $comment, $gcos, $dir, $shell) = getpwuid($st_uid);
|
|
|
|
if (!defined $gcos) {
|
|
|
|
return undef;
|
|
|
|
}
|
|
|
|
my $owner = $gcos;
|
|
|
|
$owner =~ s/[,;].*$//;
|
|
|
|
return $owner;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:27:18 +02:00
|
|
|
sub git_read_projects {
|
2005-08-07 20:21:23 +02:00
|
|
|
my @list;
|
|
|
|
|
2005-08-07 20:23:12 +02:00
|
|
|
if (-d $projects_list) {
|
2005-08-07 20:21:23 +02:00
|
|
|
# search in directory
|
2005-08-07 20:23:12 +02:00
|
|
|
my $dir = $projects_list;
|
2005-08-07 20:26:27 +02:00
|
|
|
opendir my $dh, $dir or return undef;
|
2005-08-07 20:21:23 +02:00
|
|
|
while (my $dir = readdir($dh)) {
|
|
|
|
if (-e "$projectroot/$dir/HEAD") {
|
2005-08-07 20:22:44 +02:00
|
|
|
my $pr = {
|
|
|
|
path => $dir,
|
|
|
|
};
|
|
|
|
push @list, $pr
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
closedir($dh);
|
2005-08-07 20:23:12 +02:00
|
|
|
} elsif (-f $projects_list) {
|
2005-08-07 20:25:54 +02:00
|
|
|
# read from file(url-encoded):
|
|
|
|
# 'git%2Fgit.git Linus+Torvalds'
|
|
|
|
# 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
|
|
|
|
# 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd , $projects_list or return undef;
|
2005-08-07 20:21:23 +02:00
|
|
|
while (my $line = <$fd>) {
|
|
|
|
chomp $line;
|
2005-08-07 20:23:49 +02:00
|
|
|
my ($path, $owner) = split ' ', $line;
|
|
|
|
$path = unescape($path);
|
|
|
|
$owner = unescape($owner);
|
2005-08-07 20:22:44 +02:00
|
|
|
if (!defined $path) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
if (-e "$projectroot/$path/HEAD") {
|
|
|
|
my $pr = {
|
|
|
|
path => $path,
|
|
|
|
owner => $owner,
|
|
|
|
};
|
|
|
|
push @list, $pr
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
close $fd;
|
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
@list = sort {$a->{'path'} cmp $b->{'path'}} @list;
|
|
|
|
return @list;
|
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
|
2005-08-07 20:27:18 +02:00
|
|
|
sub git_project_list {
|
|
|
|
my @list = git_read_projects();
|
2005-08-10 03:53:09 +02:00
|
|
|
my @projects;
|
2005-08-07 20:21:23 +02:00
|
|
|
if (!@list) {
|
|
|
|
die_error(undef, "No project found.");
|
|
|
|
}
|
2005-08-10 03:53:09 +02:00
|
|
|
foreach my $pr (@list) {
|
|
|
|
my $head = git_read_hash("$pr->{'path'}/HEAD");
|
|
|
|
if (!defined $head) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
$ENV{'GIT_DIR'} = "$projectroot/$pr->{'path'}";
|
|
|
|
my %co = git_read_commit($head);
|
|
|
|
if (!%co) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
$pr->{'commit'} = \%co;
|
|
|
|
if (!defined $pr->{'descr'}) {
|
|
|
|
my $descr = git_read_description($pr->{'path'}) || "";
|
|
|
|
$pr->{'descr'} = chop_str($descr, 25, 5);
|
|
|
|
}
|
|
|
|
if (!defined $pr->{'owner'}) {
|
|
|
|
$pr->{'owner'} = get_file_owner("$projectroot/$pr->{'path'}") || "";
|
|
|
|
}
|
|
|
|
push @projects, $pr;
|
|
|
|
}
|
2005-08-07 20:21:04 +02:00
|
|
|
git_header_html();
|
2005-08-07 20:22:53 +02:00
|
|
|
if (-f $home_text) {
|
|
|
|
print "<div class=\"index_include\">\n";
|
2005-08-07 20:23:12 +02:00
|
|
|
open (my $fd, $home_text);
|
2005-08-07 20:22:53 +02:00
|
|
|
print <$fd>;
|
|
|
|
close $fd;
|
|
|
|
print "</div>\n";
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n" .
|
2005-08-10 03:53:09 +02:00
|
|
|
"<tr>\n";
|
2005-08-12 21:43:32 +02:00
|
|
|
if (!defined($order) || (defined($order) && ($order eq "project"))) {
|
2005-08-10 03:53:09 +02:00
|
|
|
@projects = sort {$a->{'path'} cmp $b->{'path'}} @projects;
|
|
|
|
print "<th>Project</th>\n";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<th>" . $cgi->a({-class => "header", -href => esc_url("$my_uri?o=project")}, "Project") . "</th>\n";
|
2005-08-12 21:43:32 +02:00
|
|
|
}
|
|
|
|
if (defined($order) && ($order eq "descr")) {
|
|
|
|
@projects = sort {$a->{'descr'} cmp $b->{'descr'}} @projects;
|
|
|
|
print "<th>Description</th>\n";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<th>" . $cgi->a({-class => "header", -href => esc_url("$my_uri?o=descr")}, "Description") . "</th>\n";
|
2005-08-10 03:53:09 +02:00
|
|
|
}
|
|
|
|
if (defined($order) && ($order eq "owner")) {
|
|
|
|
@projects = sort {$a->{'owner'} cmp $b->{'owner'}} @projects;
|
|
|
|
print "<th>Owner</th>\n";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<th>" . $cgi->a({-class => "header", -href => esc_url("$my_uri?o=owner")}, "Owner") . "</th>\n";
|
2005-08-10 03:53:09 +02:00
|
|
|
}
|
|
|
|
if (defined($order) && ($order eq "age")) {
|
|
|
|
@projects = sort {$a->{'commit'}{'age'} <=> $b->{'commit'}{'age'}} @projects;
|
2005-08-12 21:43:32 +02:00
|
|
|
print "<th>Last Change</th>\n";
|
2005-08-10 03:53:09 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<th>" . $cgi->a({-class => "header", -href => esc_url("$my_uri?o=age")}, "Last Change") . "</th>\n";
|
2005-08-10 03:53:09 +02:00
|
|
|
}
|
|
|
|
print "<th></th>\n" .
|
2005-08-07 20:21:34 +02:00
|
|
|
"</tr>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
my $alternate = 0;
|
2005-08-10 03:53:09 +02:00
|
|
|
foreach my $pr (@projects) {
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<td>" . $cgi->a({-href => esc_url("$my_uri?p=$pr->{'path'};a=summary"), -class => "list"}, esc_html($pr->{'path'})) . "</td>\n" .
|
2005-08-10 03:53:09 +02:00
|
|
|
"<td>$pr->{'descr'}</td>\n" .
|
|
|
|
"<td><i>" . chop_str($pr->{'owner'}, 15) . "</i></td>\n";
|
2005-08-07 20:23:12 +02:00
|
|
|
my $colored_age;
|
2005-08-10 03:53:09 +02:00
|
|
|
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>";
|
2005-08-07 20:21:04 +02:00
|
|
|
} else {
|
2005-08-10 03:53:09 +02:00
|
|
|
$colored_age = "<i>$pr->{'commit'}{'age_string'}</i>";
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:23:12 +02:00
|
|
|
print "<td>$colored_age</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$pr->{'path'};a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$pr->{'path'};a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$pr->{'path'};a=log")}, "log") .
|
2005-08-07 20:23:24 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"</tr>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:25:54 +02:00
|
|
|
print "</table>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
git_footer_html();
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:24:35 +02:00
|
|
|
sub git_read_refs {
|
|
|
|
my $ref_dir = shift;
|
2005-08-07 20:24:43 +02:00
|
|
|
my @reflist;
|
2005-08-07 20:23:12 +02:00
|
|
|
|
2005-08-07 20:27:38 +02:00
|
|
|
my @refs;
|
2005-08-07 20:24:35 +02:00
|
|
|
opendir my $dh, "$projectroot/$project/$ref_dir";
|
2005-08-07 20:27:38 +02:00
|
|
|
while (my $dir = readdir($dh)) {
|
|
|
|
if ($dir =~ m/^\./) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
if (-d "$projectroot/$project/$ref_dir/$dir") {
|
|
|
|
opendir my $dh2, "$projectroot/$project/$ref_dir/$dir";
|
|
|
|
my @subdirs = grep !m/^\./, readdir $dh2;
|
|
|
|
closedir($dh2);
|
|
|
|
foreach my $subdir (@subdirs) {
|
|
|
|
push @refs, "$dir/$subdir"
|
|
|
|
}
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
push @refs, $dir;
|
|
|
|
}
|
2005-08-07 20:23:12 +02:00
|
|
|
closedir($dh);
|
2005-08-07 20:24:43 +02:00
|
|
|
foreach my $ref_file (@refs) {
|
|
|
|
my $ref_id = git_read_hash("$project/$ref_dir/$ref_file");
|
|
|
|
my $type = git_get_type($ref_id) || next;
|
|
|
|
my %ref_item;
|
2005-08-07 20:23:12 +02:00
|
|
|
my %co;
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'type'} = $type;
|
|
|
|
$ref_item{'id'} = $ref_id;
|
2005-08-07 20:29:03 +02:00
|
|
|
$ref_item{'epoch'} = 0;
|
|
|
|
$ref_item{'age'} = "unknown";
|
2005-08-07 20:23:12 +02:00
|
|
|
if ($type eq "tag") {
|
2005-08-07 20:24:43 +02:00
|
|
|
my %tag = git_read_tag($ref_id);
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'comment'} = $tag{'comment'};
|
2005-08-07 20:23:12 +02:00
|
|
|
if ($tag{'type'} eq "commit") {
|
|
|
|
%co = git_read_commit($tag{'object'});
|
2005-08-07 20:29:03 +02:00
|
|
|
$ref_item{'epoch'} = $co{'committer_epoch'};
|
|
|
|
$ref_item{'age'} = $co{'age_string'};
|
|
|
|
} elsif (defined($tag{'epoch'})) {
|
|
|
|
my $age = time - $tag{'epoch'};
|
|
|
|
$ref_item{'epoch'} = $tag{'epoch'};
|
|
|
|
$ref_item{'age'} = age_string($age);
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'reftype'} = $tag{'type'};
|
2005-08-07 20:24:43 +02:00
|
|
|
$ref_item{'name'} = $tag{'name'};
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'refid'} = $tag{'object'};
|
2005-08-07 20:23:12 +02:00
|
|
|
} elsif ($type eq "commit"){
|
2005-08-07 20:24:43 +02:00
|
|
|
%co = git_read_commit($ref_id);
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'reftype'} = "commit";
|
2005-08-07 20:24:43 +02:00
|
|
|
$ref_item{'name'} = $ref_file;
|
|
|
|
$ref_item{'title'} = $co{'title'};
|
2005-08-07 20:28:53 +02:00
|
|
|
$ref_item{'refid'} = $ref_id;
|
2005-08-07 20:29:03 +02:00
|
|
|
$ref_item{'epoch'} = $co{'committer_epoch'};
|
|
|
|
$ref_item{'age'} = $co{'age_string'};
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:24:43 +02:00
|
|
|
push @reflist, \%ref_item;
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
|
|
|
# sort tags by age
|
2005-08-07 20:24:43 +02:00
|
|
|
@reflist = sort {$b->{'epoch'} <=> $a->{'epoch'}} @reflist;
|
|
|
|
return \@reflist;
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
sub git_summary {
|
|
|
|
my $descr = git_read_description($project) || "none";
|
|
|
|
my $head = git_read_hash("$project/HEAD");
|
|
|
|
my %co = git_read_commit($head);
|
|
|
|
my %cd = date_str($co{'committer_epoch'}, $co{'committer_tz'});
|
|
|
|
|
|
|
|
my $owner;
|
|
|
|
if (-f $projects_list) {
|
|
|
|
open (my $fd , $projects_list);
|
|
|
|
while (my $line = <$fd>) {
|
|
|
|
chomp $line;
|
2005-08-07 20:23:49 +02:00
|
|
|
my ($pr, $ow) = split ' ', $line;
|
|
|
|
$pr = unescape($pr);
|
|
|
|
$ow = unescape($ow);
|
2005-08-07 20:23:12 +02:00
|
|
|
if ($pr eq $project) {
|
|
|
|
$owner = $ow;
|
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
close $fd;
|
|
|
|
}
|
|
|
|
if (!defined $owner) {
|
|
|
|
$owner = get_file_owner("$projectroot/$project");
|
|
|
|
}
|
|
|
|
|
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"summary".
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$head")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$head")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree")}, "tree") .
|
2005-08-07 20:23:12 +02:00
|
|
|
"<br/><br/>\n" .
|
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"title\"> </div>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<tr><td>description</td><td>" . esc_html($descr) . "</td></tr>\n" .
|
2005-08-07 20:23:12 +02:00
|
|
|
"<tr><td>owner</td><td>$owner</td></tr>\n" .
|
|
|
|
"<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
|
2005-08-07 20:25:42 +02:00
|
|
|
"</table>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_hash("$project/HEAD") or die_error(undef, "Open failed.");
|
2005-08-07 20:23:12 +02:00
|
|
|
my (@revlist) = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd;
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog"), -class => "title"}, "shortlog") .
|
2005-08-07 20:23:12 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
my $i = 16;
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:23:12 +02:00
|
|
|
foreach my $commit (@revlist) {
|
|
|
|
my %co = git_read_commit($commit);
|
|
|
|
my %ad = date_str($co{'author_epoch'});
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:26:27 +02:00
|
|
|
if ($i-- > 0) {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td><i>$co{'age_string'}</i></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
|
2005-08-31 03:47:13 +02:00
|
|
|
"<td>";
|
|
|
|
if (length($co{'title_short'}) < length($co{'title'})) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
|
|
|
|
"<b>" . esc_html($co{'title_short'}) . "</b>");
|
2005-08-31 03:47:13 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "list"},
|
|
|
|
"<b>" . esc_html($co{'title'}) . "</b>");
|
2005-08-31 03:47:13 +02:00
|
|
|
}
|
2005-08-31 04:11:33 +02:00
|
|
|
print "</td>\n" .
|
2005-08-07 20:24:51 +02:00
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
|
2005-08-07 20:24:51 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:24:01 +02:00
|
|
|
"</tr>";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<td>" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "...") . "</td>\n" .
|
2005-08-07 20:24:01 +02:00
|
|
|
"</tr>";
|
2005-08-07 20:23:12 +02:00
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table\n>";
|
2005-08-07 20:23:12 +02:00
|
|
|
|
2005-08-07 20:24:35 +02:00
|
|
|
my $taglist = git_read_refs("refs/tags");
|
2005-08-07 20:23:12 +02:00
|
|
|
if (defined @$taglist) {
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=tags"), -class => "title"}, "tags") .
|
2005-08-07 20:23:12 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
my $i = 16;
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:23:12 +02:00
|
|
|
foreach my $entry (@$taglist) {
|
|
|
|
my %tag = %$entry;
|
2005-08-07 20:28:53 +02:00
|
|
|
my $comment_lines = $tag{'comment'};
|
|
|
|
my $comment = shift @$comment_lines;
|
|
|
|
if (defined($comment)) {
|
|
|
|
$comment = chop_str($comment, 30, 5);
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:26:27 +02:00
|
|
|
if ($i-- > 0) {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td><i>$tag{'age'}</i></td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=$tag{'reftype'};h=$tag{'refid'}"), -class => "list"},
|
|
|
|
"<b>" . esc_html($tag{'name'}) . "</b>") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:28:53 +02:00
|
|
|
"<td>";
|
|
|
|
if (defined($comment)) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-class => "list", -href => esc_url("$my_uri?p=$project;a=tag;h=$tag{'id'}")}, $comment);
|
2005-08-07 20:28:53 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
|
|
|
"<td class=\"link\">";
|
|
|
|
if ($tag{'type'} eq "tag") {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=tag;h=$tag{'id'}")}, "tag") . " | ";
|
2005-08-07 20:28:53 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=$tag{'reftype'};h=$tag{'refid'}")}, $tag{'reftype'});
|
2005-08-07 20:28:53 +02:00
|
|
|
if ($tag{'reftype'} eq "commit") {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$tag{'refid'}")}, "log");
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
2005-08-07 20:24:01 +02:00
|
|
|
"</tr>";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<td>" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tags")}, "...") . "</td>\n" .
|
2005-08-07 20:24:01 +02:00
|
|
|
"</tr>";
|
2005-08-07 20:23:12 +02:00
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table\n>";
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
2005-08-07 20:24:35 +02:00
|
|
|
|
2005-10-04 01:12:47 +02:00
|
|
|
my $headlist = git_read_refs("refs/heads");
|
|
|
|
if (defined @$headlist) {
|
2005-08-07 20:24:35 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=heads"), -class => "title"}, "heads") .
|
2005-08-07 20:24:35 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
my $i = 16;
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-10-04 01:12:47 +02:00
|
|
|
foreach my $entry (@$headlist) {
|
2005-08-07 20:24:35 +02:00
|
|
|
my %tag = %$entry;
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:26:27 +02:00
|
|
|
if ($i-- > 0) {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td><i>$tag{'age'}</i></td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}"), -class => "list"},
|
|
|
|
"<b>" . esc_html($tag{'name'}) . "</b>") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$tag{'name'}")}, "log") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:24:35 +02:00
|
|
|
"</tr>";
|
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<td>" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=heads")}, "...") . "</td>\n" .
|
2005-08-07 20:24:35 +02:00
|
|
|
"</tr>";
|
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table\n>";
|
2005-08-07 20:24:35 +02:00
|
|
|
}
|
2005-08-07 20:23:12 +02:00
|
|
|
git_footer_html();
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:28:53 +02:00
|
|
|
sub git_tag {
|
|
|
|
my $head = git_read_hash("$project/HEAD");
|
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$head")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$head")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;hb=$head")}, "tree") . "<br/>\n" .
|
2005-08-07 20:28:53 +02:00
|
|
|
"<br/>\n" .
|
|
|
|
"</div>\n";
|
|
|
|
my %tag = git_read_tag($hash);
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($tag{'name'})) . "\n" .
|
2005-08-07 20:28:53 +02:00
|
|
|
"</div>\n";
|
|
|
|
print "<div class=\"title_text\">\n" .
|
|
|
|
"<table cellspacing=\"0\">\n" .
|
2005-08-08 00:02:39 +02:00
|
|
|
"<tr>\n" .
|
|
|
|
"<td>object</td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td>" . $cgi->a({-class => "list", -href => esc_url("$my_uri?p=$project;a=$tag{'type'};h=$tag{'object'}")}, $tag{'object'}) . "</td>\n" .
|
|
|
|
"<td class=\"link\">" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=$tag{'type'};h=$tag{'object'}")}, $tag{'type'}) . "</td>\n" .
|
2005-08-08 00:02:39 +02:00
|
|
|
"</tr>\n";
|
2005-08-07 20:28:53 +02:00
|
|
|
if (defined($tag{'author'})) {
|
|
|
|
my %ad = date_str($tag{'epoch'}, $tag{'tz'});
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<tr><td>author</td><td>" . esc_html($tag{'author'}) . "</td></tr>\n";
|
2005-08-07 20:28:53 +02:00
|
|
|
print "<tr><td></td><td>" . $ad{'rfc2822'} . sprintf(" (%02d:%02d %s)", $ad{'hour_local'}, $ad{'minute_local'}, $ad{'tz_local'}) . "</td></tr>\n";
|
|
|
|
}
|
|
|
|
print "</table>\n\n" .
|
|
|
|
"</div>\n";
|
|
|
|
print "<div class=\"page_body\">";
|
|
|
|
my $comment = $tag{'comment'};
|
|
|
|
foreach my $line (@$comment) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print esc_html($line) . "<br/>\n";
|
2005-08-07 20:28:53 +02:00
|
|
|
}
|
|
|
|
print "</div>\n";
|
|
|
|
git_footer_html();
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:23:12 +02:00
|
|
|
sub git_tags {
|
|
|
|
my $head = git_read_hash("$project/HEAD");
|
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$head")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$head")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;hb=$head")}, "tree") . "<br/>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<br/>\n" .
|
2005-08-07 20:23:12 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:24:35 +02:00
|
|
|
my $taglist = git_read_refs("refs/tags");
|
2005-08-07 20:23:12 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary"), -class => "title"}, " ") .
|
2005-08-07 20:23:12 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:23:12 +02:00
|
|
|
if (defined @$taglist) {
|
|
|
|
foreach my $entry (@$taglist) {
|
|
|
|
my %tag = %$entry;
|
2005-08-07 20:28:53 +02:00
|
|
|
my $comment_lines = $tag{'comment'};
|
|
|
|
my $comment = shift @$comment_lines;
|
|
|
|
if (defined($comment)) {
|
|
|
|
$comment = chop_str($comment, 30, 5);
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
|
|
|
print "<td><i>$tag{'age'}</i></td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=$tag{'reftype'};h=$tag{'refid'}"), -class => "list"},
|
|
|
|
"<b>" . esc_html($tag{'name'}) . "</b>") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:28:53 +02:00
|
|
|
"<td>";
|
|
|
|
if (defined($comment)) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-class => "list", -href => esc_url("$my_uri?p=$project;a=tag;h=$tag{'id'}")}, $comment);
|
2005-08-07 20:28:53 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
|
|
|
"<td class=\"link\">";
|
|
|
|
if ($tag{'type'} eq "tag") {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=tag;h=$tag{'id'}")}, "tag") . " | ";
|
2005-08-07 20:28:53 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=$tag{'reftype'};h=$tag{'refid'}")}, $tag{'reftype'});
|
2005-08-07 20:28:53 +02:00
|
|
|
if ($tag{'reftype'} eq "commit") {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$tag{'refid'}")}, "log");
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
2005-08-07 20:25:27 +02:00
|
|
|
"</tr>";
|
2005-08-07 20:23:12 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table\n>";
|
2005-08-07 20:23:12 +02:00
|
|
|
git_footer_html();
|
|
|
|
}
|
|
|
|
|
2005-10-04 01:12:47 +02:00
|
|
|
sub git_heads {
|
2005-08-07 20:24:35 +02:00
|
|
|
my $head = git_read_hash("$project/HEAD");
|
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$head")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$head")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;hb=$head")}, "tree") . "<br/>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<br/>\n" .
|
2005-08-07 20:24:35 +02:00
|
|
|
"</div>\n";
|
|
|
|
my $taglist = git_read_refs("refs/heads");
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary"), -class => "title"}, " ") .
|
2005-08-07 20:24:35 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:24:35 +02:00
|
|
|
if (defined @$taglist) {
|
|
|
|
foreach my $entry (@$taglist) {
|
|
|
|
my %tag = %$entry;
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
|
|
|
print "<td><i>$tag{'age'}</i></td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}"), -class => "list"}, "<b>" . esc_html($tag{'name'}) . "</b>") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$tag{'name'}")}, "log") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:25:27 +02:00
|
|
|
"</tr>";
|
2005-08-07 20:24:35 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table\n>";
|
2005-08-07 20:24:35 +02:00
|
|
|
git_footer_html();
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_get_hash_by_path {
|
|
|
|
my $base = shift;
|
2005-08-07 20:26:27 +02:00
|
|
|
my $path = shift || return undef;
|
2005-08-07 20:21:23 +02:00
|
|
|
|
|
|
|
my $tree = $base;
|
|
|
|
my @parts = split '/', $path;
|
|
|
|
while (my $part = shift @parts) {
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-ls-tree $tree" or die_error(undef, "Open git-ls-tree failed.");
|
2005-08-07 20:21:23 +02:00
|
|
|
my (@entries) = map { chomp; $_ } <$fd>;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or return undef;
|
2005-08-07 20:21:23 +02:00
|
|
|
foreach my $line (@entries) {
|
|
|
|
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
|
2005-08-07 20:26:27 +02:00
|
|
|
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/;
|
2005-08-07 20:21:23 +02:00
|
|
|
my $t_mode = $1;
|
|
|
|
my $t_type = $2;
|
|
|
|
my $t_hash = $3;
|
|
|
|
my $t_name = $4;
|
|
|
|
if ($t_name eq $part) {
|
|
|
|
if (!(@parts)) {
|
|
|
|
return $t_hash;
|
|
|
|
}
|
|
|
|
if ($t_type eq "tree") {
|
|
|
|
$tree = $t_hash;
|
|
|
|
}
|
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sub git_blob {
|
|
|
|
if (!defined $hash && defined $file_name) {
|
2005-08-07 20:23:12 +02:00
|
|
|
my $base = $hash_base || git_read_hash("$project/HEAD");
|
2005-08-07 20:21:23 +02:00
|
|
|
$hash = git_get_hash_by_path($base, $file_name, "blob");
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
|
2005-08-07 20:02:47 +02:00
|
|
|
git_header_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash_base")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash_base")}, "tree") . "<br/>\n";
|
2005-10-17 03:27:54 +02:00
|
|
|
if (defined $file_name) {
|
2005-11-20 02:03:09 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob_plain;h=$hash;f=$file_name")}, "plain") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;hb=HEAD;f=$file_name")}, "head") . "<br/>\n";
|
2005-10-17 03:27:54 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob_plain;h=$hash")}, "plain") . "<br/>\n";
|
2005-10-17 03:27:54 +02:00
|
|
|
}
|
|
|
|
print "</div>\n".
|
|
|
|
"<div>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base"), -class => "title"}, esc_html($co{'title'})) .
|
2005-08-07 20:22:44 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
} else {
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
|
|
|
"<br/><br/></div>\n" .
|
|
|
|
"<div class=\"title\">$hash</div>\n";
|
|
|
|
}
|
|
|
|
if (defined $file_name) {
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"page_path\"><b>$file_name</b></div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
2005-08-07 20:22:44 +02:00
|
|
|
print "<div class=\"page_body\">\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
my $nr;
|
|
|
|
while (my $line = <$fd>) {
|
2005-08-07 20:22:44 +02:00
|
|
|
chomp $line;
|
2005-08-07 19:49:46 +02:00
|
|
|
$nr++;
|
2005-08-07 20:26:27 +02:00
|
|
|
while ((my $pos = index($line, "\t")) != -1) {
|
|
|
|
if (my $count = (8 - ($pos % 8))) {
|
|
|
|
my $spaces = ' ' x $count;
|
|
|
|
$line =~ s/\t/$spaces/;
|
|
|
|
}
|
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n", $nr, $nr, $nr, esc_html($line);
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or print "Reading blob failed.\n";
|
2005-08-07 20:12:11 +02:00
|
|
|
print "</div>";
|
2005-08-07 20:02:47 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
sub git_blob_plain {
|
2005-10-17 03:27:54 +02:00
|
|
|
my $save_as = "$hash.txt";
|
|
|
|
if (defined $file_name) {
|
|
|
|
$save_as = $file_name;
|
|
|
|
}
|
|
|
|
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"$save_as\"");
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or return;
|
|
|
|
undef $/;
|
|
|
|
print <$fd>;
|
|
|
|
$/ = "\n";
|
|
|
|
close $fd;
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_tree {
|
2005-08-07 20:21:04 +02:00
|
|
|
if (!defined $hash) {
|
2005-08-07 20:23:12 +02:00
|
|
|
$hash = git_read_hash("$project/HEAD");
|
2005-08-07 20:21:23 +02:00
|
|
|
if (defined $file_name) {
|
2005-08-07 20:23:12 +02:00
|
|
|
my $base = $hash_base || git_read_hash("$project/HEAD");
|
2005-08-07 20:21:23 +02:00
|
|
|
$hash = git_get_hash_by_path($base, $file_name, "tree");
|
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
if (!defined $hash_base) {
|
|
|
|
$hash_base = git_read_hash("$project/HEAD");
|
|
|
|
}
|
2005-08-07 20:23:35 +02:00
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-ls-tree $hash" or die_error(undef, "Open git-ls-tree failed.");
|
2005-08-07 19:49:46 +02:00
|
|
|
my (@entries) = map { chomp; $_ } <$fd>;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or die_error(undef, "Reading tree failed.");
|
2005-08-07 20:18:13 +02:00
|
|
|
|
2005-08-07 20:02:47 +02:00
|
|
|
git_header_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
my $base_key = "";
|
|
|
|
my $file_key = "";
|
|
|
|
my $base = "";
|
|
|
|
if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
|
|
|
|
$base_key = ";hb=$hash_base";
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash_base")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash_base")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash_base")}, "commitdiff") .
|
2005-08-07 20:26:27 +02:00
|
|
|
" | tree" .
|
2005-08-07 20:19:56 +02:00
|
|
|
"<br/><br/>\n" .
|
|
|
|
"</div>\n";
|
2005-08-07 20:18:13 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:18:13 +02:00
|
|
|
"</div>\n";
|
|
|
|
} else {
|
|
|
|
print "<div class=\"page_nav\">\n";
|
|
|
|
print "<br/><br/></div>\n";
|
|
|
|
print "<div class=\"title\">$hash</div>\n";
|
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
if (defined $file_name) {
|
|
|
|
$base = "$file_name/";
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"page_path\"><b>/$file_name</b></div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
} else {
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"page_path\"><b>/</b></div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
2005-08-07 20:12:11 +02:00
|
|
|
print "<div class=\"page_body\">\n";
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
my $alternate = 0;
|
2005-08-07 19:49:46 +02:00
|
|
|
foreach my $line (@entries) {
|
2005-08-07 19:56:10 +02:00
|
|
|
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
|
2005-08-07 20:26:27 +02:00
|
|
|
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t(.+)$/;
|
2005-08-07 20:05:55 +02:00
|
|
|
my $t_mode = $1;
|
2005-08-07 19:49:46 +02:00
|
|
|
my $t_type = $2;
|
|
|
|
my $t_hash = $3;
|
|
|
|
my $t_name = $4;
|
2005-08-07 20:21:23 +02:00
|
|
|
$file_key = ";f=$base$t_name";
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
|
|
|
print "<td style=\"font-family:monospace\">" . mode_str($t_mode) . "</td>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
if ($t_type eq "blob") {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td class=\"list\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$t_hash" . $base_key . $file_key), -class => "list"}, $t_name) .
|
2005-08-07 20:27:18 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$t_hash" . $base_key . $file_key)}, "blob") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=history;h=$hash_base" . $file_key)}, "history") .
|
2005-08-07 20:21:46 +02:00
|
|
|
"</td>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
} elsif ($t_type eq "tree") {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td class=\"list\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$t_hash" . $base_key . $file_key)}, $t_name) .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<td class=\"link\">" .
|
2005-11-20 02:03:09 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$t_hash" . $base_key . $file_key)}, "tree") .
|
2005-08-07 20:27:18 +02:00
|
|
|
"</td>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:21:46 +02:00
|
|
|
print "</tr>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:21:46 +02:00
|
|
|
print "</table>\n" .
|
|
|
|
"</div>";
|
2005-08-07 20:02:47 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
sub git_rss {
|
2005-08-07 20:26:27 +02:00
|
|
|
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
|
2005-08-12 21:43:32 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_hash("$project/HEAD") or die_error(undef, "Open failed.");
|
2005-08-07 20:16:07 +02:00
|
|
|
my (@revlist) = map { chomp; $_ } <$fd>;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or die_error(undef, "Reading rev-list failed.");
|
2005-08-07 20:20:07 +02:00
|
|
|
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
|
|
|
|
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
|
2005-08-07 20:26:27 +02:00
|
|
|
"<rss version=\"2.0\" xmlns:content=\"http://purl.org/rss/1.0/modules/content/\">\n";
|
2005-08-07 20:20:07 +02:00
|
|
|
print "<channel>\n";
|
|
|
|
print "<title>$project</title>\n".
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<link>" . esc_html("$my_url?p=$project;a=summary") . "</link>\n".
|
2005-08-07 20:20:07 +02:00
|
|
|
"<description>$project log</description>\n".
|
|
|
|
"<language>en</language>\n";
|
|
|
|
|
2005-08-12 21:43:32 +02:00
|
|
|
for (my $i = 0; $i <= $#revlist; $i++) {
|
|
|
|
my $commit = $revlist[$i];
|
2005-08-07 20:21:23 +02:00
|
|
|
my %co = git_read_commit($commit);
|
2005-08-12 21:43:32 +02:00
|
|
|
# we read 150, we always show 30 and the ones more recent than 48 hours
|
|
|
|
if (($i >= 20) && ((time - $co{'committer_epoch'}) > 48*60*60)) {
|
|
|
|
last;
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
my %cd = date_str($co{'committer_epoch'});
|
2005-08-12 21:43:32 +02:00
|
|
|
open $fd, "-|", "$gitbin/git-diff-tree -r $co{'parent'} $co{'id'}" or next;
|
|
|
|
my @difftree = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd or next;
|
2005-08-07 20:20:07 +02:00
|
|
|
print "<item>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<title>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
sprintf("%d %s %02d:%02d", $cd{'mday'}, $cd{'month'}, $cd{'hour'}, $cd{'minute'}) . " - " . esc_html($co{'title'}) .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</title>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<author>" . esc_html($co{'author'}) . "</author>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<pubDate>$cd{'rfc2822'}</pubDate>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<guid isPermaLink=\"true\">" . esc_html("$my_url?p=$project;a=commit;h=$commit") . "</guid>\n" .
|
|
|
|
"<link>" . esc_html("$my_url?p=$project;a=commit;h=$commit") . "</link>\n" .
|
|
|
|
"<description>" . esc_html($co{'title'}) . "</description>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<content:encoded>" .
|
|
|
|
"<![CDATA[\n";
|
2005-08-07 20:20:07 +02:00
|
|
|
my $comment = $co{'comment'};
|
|
|
|
foreach my $line (@$comment) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$line = decode("utf8", $line, Encode::FB_DEFAULT);
|
2005-08-07 20:26:27 +02:00
|
|
|
print "$line<br/>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-12 21:43:32 +02:00
|
|
|
print "<br/>\n";
|
|
|
|
foreach my $line (@difftree) {
|
|
|
|
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
my $file = $7;
|
|
|
|
print "$file<br/>\n";
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
print "]]>\n" .
|
|
|
|
"</content:encoded>\n" .
|
2005-08-07 20:20:07 +02:00
|
|
|
"</item>\n";
|
|
|
|
}
|
|
|
|
print "</channel></rss>";
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:27:18 +02:00
|
|
|
sub git_opml {
|
|
|
|
my @list = git_read_projects();
|
|
|
|
|
|
|
|
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
|
|
|
|
print "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n".
|
|
|
|
"<opml version=\"1.0\">\n".
|
|
|
|
"<head>".
|
|
|
|
" <title>Git OPML Export</title>\n".
|
|
|
|
"</head>\n".
|
|
|
|
"<body>\n".
|
|
|
|
"<outline text=\"git RSS feeds\">\n";
|
|
|
|
|
|
|
|
foreach my $pr (@list) {
|
|
|
|
my %proj = %$pr;
|
|
|
|
my $head = git_read_hash("$proj{'path'}/HEAD");
|
|
|
|
if (!defined $head) {
|
|
|
|
next;
|
|
|
|
}
|
2005-08-07 20:27:38 +02:00
|
|
|
$ENV{'GIT_DIR'} = "$projectroot/$proj{'path'}";
|
2005-08-07 20:27:18 +02:00
|
|
|
my %co = git_read_commit($head);
|
|
|
|
if (!%co) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $path = esc_html(chop_str($proj{'path'}, 25, 5));
|
2005-08-07 20:27:18 +02:00
|
|
|
my $rss = "$my_url?p=$proj{'path'};a=rss";
|
2005-08-07 20:27:27 +02:00
|
|
|
my $html = "$my_url?p=$proj{'path'};a=summary";
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<outline type=\"rss\" text=\"$path\" title=\"$path\" xmlUrl=\"$rss\" htmlUrl=\"$html\"/>\n";
|
|
|
|
}
|
|
|
|
print "</outline>\n".
|
|
|
|
"</body>\n".
|
|
|
|
"</opml>\n";
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_log {
|
2005-08-07 20:26:27 +02:00
|
|
|
my $head = git_read_hash("$project/HEAD");
|
2005-08-07 20:24:35 +02:00
|
|
|
if (!defined $hash) {
|
2005-08-07 20:26:27 +02:00
|
|
|
$hash = $head;
|
2005-08-07 20:24:35 +02:00
|
|
|
}
|
2005-08-07 20:26:49 +02:00
|
|
|
if (!defined $page) {
|
|
|
|
$page = 0;
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:20:07 +02:00
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash")}, "shortlog") .
|
2005-08-07 20:26:27 +02:00
|
|
|
" | log" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
|
2005-08-07 20:26:49 +02:00
|
|
|
|
|
|
|
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
|
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
|
|
|
|
my (@revlist) = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd;
|
|
|
|
|
|
|
|
if ($hash ne $head || $page) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "HEAD");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print "HEAD";
|
|
|
|
}
|
|
|
|
if ($page > 0) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print " ⋅ " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash;pg=" . ($page-1)), -accesskey => "p", -title => "Alt-p"}, "prev");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print " ⋅ prev";
|
|
|
|
}
|
|
|
|
if ($#revlist >= (100 * ($page+1)-1)) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print " ⋅ " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash;pg=" . ($page+1)), -accesskey => "n", -title => "Alt-n"}, "next");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print " ⋅ next";
|
|
|
|
}
|
2005-08-07 20:23:12 +02:00
|
|
|
print "<br/>\n" .
|
2005-08-07 20:20:07 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
if (!@revlist) {
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary"), -class => "title"}, " ") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:24:35 +02:00
|
|
|
my %co = git_read_commit($hash);
|
2005-08-07 20:23:35 +02:00
|
|
|
print "<div class=\"page_body\"> Last change $co{'age_string'}.<br/><br/></div>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
for (my $i = ($page * 100); $i <= $#revlist; $i++) {
|
|
|
|
my $commit = $revlist[$i];
|
2005-08-07 20:21:23 +02:00
|
|
|
my %co = git_read_commit($commit);
|
2005-08-07 20:21:04 +02:00
|
|
|
next if !%co;
|
2005-08-07 20:20:07 +02:00
|
|
|
my %ad = date_str($co{'author_epoch'});
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "title"},
|
|
|
|
"<span class=\"age\">$co{'age_string'}</span>" . esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:20:07 +02:00
|
|
|
"</div>\n";
|
|
|
|
print "<div class=\"title_text\">\n" .
|
|
|
|
"<div class=\"log_link\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
|
2005-08-07 20:21:34 +02:00
|
|
|
"<br/>\n" .
|
2005-08-07 20:20:07 +02:00
|
|
|
"</div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<i>" . esc_html($co{'author_name'}) . " [$ad{'rfc2822'}]</i><br/>\n" .
|
2005-08-07 20:20:07 +02:00
|
|
|
"</div>\n" .
|
|
|
|
"<div class=\"log_body\">\n";
|
|
|
|
my $comment = $co{'comment'};
|
2005-08-07 20:21:23 +02:00
|
|
|
my $empty = 0;
|
2005-08-07 20:20:07 +02:00
|
|
|
foreach my $line (@$comment) {
|
2005-08-07 20:25:27 +02:00
|
|
|
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
|
2005-08-07 20:21:23 +02:00
|
|
|
next;
|
|
|
|
}
|
|
|
|
if ($line eq "") {
|
|
|
|
if ($empty) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
$empty = 1;
|
|
|
|
} else {
|
|
|
|
$empty = 0;
|
|
|
|
}
|
2005-08-07 20:28:42 +02:00
|
|
|
print format_log_line_html($line) . "<br/>\n";
|
2005-08-07 20:20:07 +02:00
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
if (!$empty) {
|
|
|
|
print "<br/>\n";
|
|
|
|
}
|
|
|
|
print "</div>\n";
|
2005-08-07 20:02:33 +02:00
|
|
|
}
|
2005-08-07 20:20:07 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
sub git_commit {
|
|
|
|
my %co = git_read_commit($hash);
|
2005-08-07 20:20:07 +02:00
|
|
|
if (!%co) {
|
2005-08-07 20:21:23 +02:00
|
|
|
die_error(undef, "Unknown commit object.");
|
2005-08-07 20:18:13 +02:00
|
|
|
}
|
2005-08-07 20:13:11 +02:00
|
|
|
my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
|
|
|
|
my %cd = date_str($co{'committer_epoch'}, $co{'committer_tz'});
|
2005-08-07 19:49:46 +02:00
|
|
|
|
2005-08-07 20:19:56 +02:00
|
|
|
my @difftree;
|
2005-08-07 20:26:27 +02:00
|
|
|
my $root = "";
|
2005-08-07 20:28:53 +02:00
|
|
|
my $parent = $co{'parent'};
|
|
|
|
if (!defined $parent) {
|
2005-08-07 20:26:27 +02:00
|
|
|
$root = " --root";
|
2005-08-07 20:28:53 +02:00
|
|
|
$parent = "";
|
2005-08-07 20:19:56 +02:00
|
|
|
}
|
2005-08-07 20:28:53 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
|
2005-08-07 20:26:27 +02:00
|
|
|
@difftree = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd or die_error(undef, "Reading diff-tree failed.");
|
2005-10-19 03:18:45 +02:00
|
|
|
|
|
|
|
# non-textual hash id's can be cached
|
|
|
|
my $expires;
|
|
|
|
if ($hash =~ m/^[0-9a-fA-F]{40}$/) {
|
|
|
|
$expires = "+1d";
|
|
|
|
}
|
|
|
|
git_header_html(undef, $expires);
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash")}, "log") .
|
2005-08-07 20:26:27 +02:00
|
|
|
" | commit";
|
2005-08-07 20:21:46 +02:00
|
|
|
if (defined $co{'parent'}) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash")}, "commitdiff");
|
2005-08-07 20:21:46 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") . "\n" .
|
2005-08-07 20:13:02 +02:00
|
|
|
"<br/><br/></div>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
if (defined $co{'parent'}) {
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:21:04 +02:00
|
|
|
"</div>\n";
|
|
|
|
} else {
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:21:04 +02:00
|
|
|
"</div>\n";
|
|
|
|
}
|
2005-08-07 20:19:56 +02:00
|
|
|
print "<div class=\"title_text\">\n" .
|
2005-08-07 20:21:04 +02:00
|
|
|
"<table cellspacing=\"0\">\n";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<tr><td>author</td><td>" . esc_html($co{'author'}) . "</td></tr>\n".
|
2005-08-07 20:25:42 +02:00
|
|
|
"<tr>" .
|
|
|
|
"<td></td><td> $ad{'rfc2822'}";
|
2005-08-07 20:18:44 +02:00
|
|
|
if ($ad{'hour_local'} < 6) {
|
2005-08-07 20:21:04 +02:00
|
|
|
printf(" (<span style=\"color: #cc0000;\">%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'});
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</td>" .
|
|
|
|
"</tr>\n";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<tr><td>committer</td><td>" . esc_html($co{'committer'}) . "</td></tr>\n";
|
2005-08-07 20:23:35 +02:00
|
|
|
print "<tr><td></td><td> $cd{'rfc2822'}" . sprintf(" (%02d:%02d %s)", $cd{'hour_local'}, $cd{'minute_local'}, $cd{'tz_local'}) . "</td></tr>\n";
|
2005-09-04 01:37:25 +02:00
|
|
|
print "<tr><td>commit</td><td style=\"font-family:monospace\">$co{'id'}</td></tr>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<tr>" .
|
|
|
|
"<td>tree</td>" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td style=\"font-family:monospace\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash"), class => "list"}, $co{'tree'}) .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td class=\"link\">" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") .
|
2005-08-07 20:25:42 +02:00
|
|
|
"</td>" .
|
|
|
|
"</tr>\n";
|
2005-08-07 20:05:15 +02:00
|
|
|
my $parents = $co{'parents'};
|
|
|
|
foreach my $par (@$parents) {
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<tr>" .
|
|
|
|
"<td>parent</td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td style=\"font-family:monospace\">" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$par"), class => "list"}, $par) . "</td>" .
|
2005-08-07 20:25:42 +02:00
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$par")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash;hp=$par")}, "commitdiff") .
|
2005-08-07 20:25:42 +02:00
|
|
|
"</td>" .
|
|
|
|
"</tr>\n";
|
2005-08-07 20:05:15 +02:00
|
|
|
}
|
2005-08-07 20:21:04 +02:00
|
|
|
print "</table>".
|
|
|
|
"</div>\n";
|
2005-08-07 20:12:11 +02:00
|
|
|
print "<div class=\"page_body\">\n";
|
2005-08-07 20:05:15 +02:00
|
|
|
my $comment = $co{'comment'};
|
2005-08-07 20:21:23 +02:00
|
|
|
my $empty = 0;
|
|
|
|
my $signed = 0;
|
2005-08-07 20:05:15 +02:00
|
|
|
foreach my $line (@$comment) {
|
2005-08-07 20:21:23 +02:00
|
|
|
# print only one empty line
|
|
|
|
if ($line eq "") {
|
|
|
|
if ($empty || $signed) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
$empty = 1;
|
|
|
|
} else {
|
|
|
|
$empty = 0;
|
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
|
2005-08-07 20:21:23 +02:00
|
|
|
$signed = 1;
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print "<span style=\"color: #888888\">" . esc_html($line) . "</span><br/>\n";
|
2005-08-07 20:05:15 +02:00
|
|
|
} else {
|
2005-08-07 20:21:23 +02:00
|
|
|
$signed = 0;
|
2005-08-07 20:28:42 +02:00
|
|
|
print format_log_line_html($line) . "<br/>\n";
|
2005-08-07 20:05:15 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:18:44 +02:00
|
|
|
print "</div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
print "<div class=\"list_head\">\n";
|
2005-08-07 20:19:56 +02:00
|
|
|
if ($#difftree > 10) {
|
2005-08-07 20:21:23 +02:00
|
|
|
print(($#difftree + 1) . " files changed:\n");
|
2005-08-07 20:19:56 +02:00
|
|
|
}
|
2005-08-07 20:21:23 +02:00
|
|
|
print "</div>\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 19:49:46 +02:00
|
|
|
foreach my $line (@difftree) {
|
2005-08-07 20:26:27 +02:00
|
|
|
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
|
|
|
|
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
|
2005-08-07 20:28:53 +02:00
|
|
|
if (!($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)([0-9]{0,3})\t(.*)$/)) {
|
|
|
|
next;
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
my $from_mode = $1;
|
|
|
|
my $to_mode = $2;
|
|
|
|
my $from_id = $3;
|
|
|
|
my $to_id = $4;
|
|
|
|
my $status = $5;
|
2005-08-07 20:26:49 +02:00
|
|
|
my $similarity = $6;
|
2005-08-07 20:26:38 +02:00
|
|
|
my $file = $7;
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:28:33 +02:00
|
|
|
if ($status eq "A") {
|
2005-08-07 20:25:27 +02:00
|
|
|
my $mode_chng = "";
|
2005-08-07 20:26:27 +02:00
|
|
|
if (S_ISREG(oct $to_mode)) {
|
|
|
|
$mode_chng = sprintf(" with mode: %04o", (oct $to_mode) & 0777);
|
2005-08-07 20:25:27 +02:00
|
|
|
}
|
|
|
|
print "<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file)) . "</td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td><span style=\"color: #008000;\">[new " . file_type($to_mode) . "$mode_chng]</span></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td class=\"link\">" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file")}, "blob") . "</td>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($status eq "D") {
|
2005-08-07 20:25:27 +02:00
|
|
|
print "<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$from_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file)) . "</td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td><span style=\"color: #c00000;\">[deleted " . file_type($from_mode). "]</span></td>\n" .
|
2005-08-07 20:25:27 +02:00
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$from_id;hb=$hash;f=$file")}, "blob") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=history;h=$hash;f=$file")}, "history") .
|
2005-08-07 20:25:27 +02:00
|
|
|
"</td>\n"
|
2005-08-07 20:26:27 +02:00
|
|
|
} elsif ($status eq "M" || $status eq "T") {
|
2005-08-07 20:25:27 +02:00
|
|
|
my $mode_chnge = "";
|
|
|
|
if ($from_mode != $to_mode) {
|
|
|
|
$mode_chnge = " <span style=\"color: #777777;\">[changed";
|
|
|
|
if (((oct $from_mode) & S_IFMT) != ((oct $to_mode) & S_IFMT)) {
|
|
|
|
$mode_chnge .= " from " . file_type($from_mode) . " to " . file_type($to_mode);
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
if (((oct $from_mode) & 0777) != ((oct $to_mode) & 0777)) {
|
|
|
|
if (S_ISREG($from_mode) && S_ISREG($to_mode)) {
|
|
|
|
$mode_chnge .= sprintf(" mode: %04o->%04o", (oct $from_mode) & 0777, (oct $to_mode) & 0777);
|
|
|
|
} elsif (S_ISREG($to_mode)) {
|
|
|
|
$mode_chnge .= sprintf(" mode: %04o", (oct $to_mode) & 0777);
|
2005-08-07 20:21:04 +02:00
|
|
|
}
|
2005-08-07 20:17:42 +02:00
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
$mode_chnge .= "]</span>\n";
|
|
|
|
}
|
|
|
|
print "<td>";
|
|
|
|
if ($to_id ne $from_id) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blobdiff;h=$to_id;hp=$from_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file));
|
2005-08-07 20:25:27 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file"), -class => "list"}, esc_html($file));
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
print "</td>\n" .
|
|
|
|
"<td>$mode_chnge</td>\n" .
|
|
|
|
"<td class=\"link\">";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file")}, "blob");
|
2005-08-07 20:25:27 +02:00
|
|
|
if ($to_id ne $from_id) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blobdiff;h=$to_id;hp=$from_id;hb=$hash;f=$file")}, "diff");
|
2005-08-07 20:25:27 +02:00
|
|
|
}
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=history;h=$hash;f=$file")}, "history") . "\n";
|
2005-08-07 20:25:27 +02:00
|
|
|
print "</td>\n";
|
2005-08-07 20:26:38 +02:00
|
|
|
} elsif ($status eq "R") {
|
|
|
|
my ($from_file, $to_file) = split "\t", $file;
|
|
|
|
my $mode_chng = "";
|
|
|
|
if ($from_mode != $to_mode) {
|
|
|
|
$mode_chng = sprintf(", mode: %04o", (oct $to_mode) & 0777);
|
|
|
|
}
|
|
|
|
print "<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$to_file"), -class => "list"}, esc_html($to_file)) . "</td>\n" .
|
2005-08-07 20:26:38 +02:00
|
|
|
"<td><span style=\"color: #777777;\">[moved from " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$from_id;hb=$hash;f=$from_file"), -class => "list"}, esc_html($from_file)) .
|
2005-08-07 20:26:49 +02:00
|
|
|
" with " . (int $similarity) . "% similarity$mode_chng]</span></td>\n" .
|
2005-08-07 20:26:38 +02:00
|
|
|
"<td class=\"link\">" .
|
2005-11-20 02:12:45 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$to_file")}, "blob");
|
2005-08-07 20:26:38 +02:00
|
|
|
if ($to_id ne $from_id) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print " | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blobdiff;h=$to_id;hp=$from_id;hb=$hash;f=$to_file")}, "diff");
|
2005-08-07 20:26:38 +02:00
|
|
|
}
|
|
|
|
print "</td>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
print "</tr>\n";
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table>\n";
|
2005-08-07 20:02:47 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
sub git_blobdiff {
|
2005-08-07 20:26:27 +02:00
|
|
|
mkdir($git_temp, 0700);
|
2005-08-07 20:02:47 +02:00
|
|
|
git_header_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
if (defined $hash_base && (my %co = git_read_commit($hash_base))) {
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash_base")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash_base")}, "tree") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<br/>\n";
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blobdiff_plain;h=$hash;hp=$hash_parent")}, "plain") .
|
2005-08-07 20:21:23 +02:00
|
|
|
"</div>\n";
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash_base"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:21:23 +02:00
|
|
|
"</div>\n";
|
|
|
|
} else {
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
|
|
|
"<br/><br/></div>\n" .
|
|
|
|
"<div class=\"title\">$hash vs $hash_parent</div>\n";
|
|
|
|
}
|
|
|
|
if (defined $file_name) {
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"page_path\"><b>/$file_name</b></div>\n";
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
2005-08-07 20:17:42 +02:00
|
|
|
print "<div class=\"page_body\">\n" .
|
2005-08-07 20:22:44 +02:00
|
|
|
"<div class=\"diff_info\">blob:" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$hash_parent;hb=$hash_base;f=$file_name")}, $hash_parent) .
|
2005-08-07 20:20:20 +02:00
|
|
|
" -> blob:" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$hash;hb=$hash_base;f=$file_name")}, $hash) .
|
2005-08-07 20:22:44 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
git_diff_print($hash_parent, $file_name || $hash_parent, $hash, $file_name || $hash);
|
2005-08-07 20:22:44 +02:00
|
|
|
print "</div>";
|
2005-08-07 20:02:47 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
sub git_blobdiff_plain {
|
|
|
|
mkdir($git_temp, 0700);
|
|
|
|
print $cgi->header(-type => "text/plain", -charset => 'utf-8');
|
|
|
|
git_diff_print($hash_parent, $file_name || $hash_parent, $hash, $file_name || $hash, "plain");
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_commitdiff {
|
2005-08-07 20:26:27 +02:00
|
|
|
mkdir($git_temp, 0700);
|
2005-08-07 20:21:23 +02:00
|
|
|
my %co = git_read_commit($hash);
|
2005-08-07 20:20:07 +02:00
|
|
|
if (!%co) {
|
2005-08-07 20:21:23 +02:00
|
|
|
die_error(undef, "Unknown commit object.");
|
2005-08-07 20:18:13 +02:00
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
if (!defined $hash_parent) {
|
|
|
|
$hash_parent = $co{'parent'};
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
|
2005-08-07 19:52:52 +02:00
|
|
|
my (@difftree) = map { chomp; $_ } <$fd>;
|
2005-08-07 20:26:27 +02:00
|
|
|
close $fd or die_error(undef, "Reading diff-tree failed.");
|
2005-08-07 19:49:46 +02:00
|
|
|
|
2005-10-19 03:18:45 +02:00
|
|
|
# non-textual hash id's can be cached
|
|
|
|
my $expires;
|
|
|
|
if ($hash =~ m/^[0-9a-fA-F]{40}$/) {
|
|
|
|
$expires = "+1d";
|
|
|
|
}
|
|
|
|
git_header_html(undef, $expires);
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash")}, "commit") .
|
2005-08-07 20:26:27 +02:00
|
|
|
" | commitdiff" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") . "<br/>\n";
|
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff_plain;h=$hash;hp=$hash_parent")}, "plain") . "\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:17:42 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:17:42 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:22:44 +02:00
|
|
|
print "<div class=\"page_body\">\n";
|
2005-08-07 20:24:35 +02:00
|
|
|
my $comment = $co{'comment'};
|
|
|
|
my $empty = 0;
|
|
|
|
my $signed = 0;
|
2005-08-07 20:24:43 +02:00
|
|
|
my @log = @$comment;
|
2005-08-07 20:24:51 +02:00
|
|
|
# remove first and empty lines after that
|
2005-08-07 20:24:43 +02:00
|
|
|
shift @log;
|
2005-08-07 20:24:51 +02:00
|
|
|
while (defined $log[0] && $log[0] eq "") {
|
|
|
|
shift @log;
|
|
|
|
}
|
2005-08-07 20:24:43 +02:00
|
|
|
foreach my $line (@log) {
|
2005-08-07 20:25:27 +02:00
|
|
|
if ($line =~ m/^ *(signed[ \-]off[ \-]by[ :]|acked[ \-]by[ :]|cc[ :])/i) {
|
2005-08-07 20:24:35 +02:00
|
|
|
next;
|
|
|
|
}
|
|
|
|
if ($line eq "") {
|
|
|
|
if ($empty) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
$empty = 1;
|
|
|
|
} else {
|
|
|
|
$empty = 0;
|
|
|
|
}
|
2005-08-07 20:28:42 +02:00
|
|
|
print format_log_line_html($line) . "<br/>\n";
|
2005-08-07 20:24:35 +02:00
|
|
|
}
|
|
|
|
print "<br/>\n";
|
2005-08-07 19:52:52 +02:00
|
|
|
foreach my $line (@difftree) {
|
2005-08-07 20:26:27 +02:00
|
|
|
# ':100644 100644 03b218260e99b78c6df0ed378e59ed9205ccc96d 3b93d5e7cc7f7dd4ebed13a5cc1a4ad976fc94d8 M ls-files.c'
|
|
|
|
# ':100644 100644 7f9281985086971d3877aca27704f2aaf9c448ce bc190ebc71bbd923f2b728e505408f5e54bd073a M rev-tree.c'
|
|
|
|
$line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/;
|
|
|
|
my $from_mode = $1;
|
|
|
|
my $to_mode = $2;
|
|
|
|
my $from_id = $3;
|
|
|
|
my $to_id = $4;
|
|
|
|
my $status = $5;
|
|
|
|
my $file = $6;
|
2005-08-07 20:28:33 +02:00
|
|
|
if ($status eq "A") {
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"diff_info\">" . file_type($to_mode) . ":" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file")}, $to_id) . "(new)" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
|
|
|
git_diff_print(undef, "/dev/null", $to_id, "b/$file");
|
|
|
|
} elsif ($status eq "D") {
|
|
|
|
print "<div class=\"diff_info\">" . file_type($from_mode) . ":" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$from_id;hb=$hash;f=$file")}, $from_id) . "(deleted)" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
|
|
|
git_diff_print($from_id, "a/$file", undef, "/dev/null");
|
|
|
|
} elsif ($status eq "M") {
|
|
|
|
if ($from_id ne $to_id) {
|
|
|
|
print "<div class=\"diff_info\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
file_type($from_mode) . ":" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$from_id;hb=$hash;f=$file")}, $from_id) .
|
2005-08-07 20:26:27 +02:00
|
|
|
" -> " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
file_type($to_mode) . ":" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$to_id;hb=$hash;f=$file")}, $to_id);
|
2005-08-07 20:26:27 +02:00
|
|
|
print "</div>\n";
|
|
|
|
git_diff_print($from_id, "a/$file", $to_id, "b/$file");
|
2005-08-07 19:52:52 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:22:44 +02:00
|
|
|
print "<br/>\n" .
|
|
|
|
"</div>";
|
2005-08-07 20:02:47 +02:00
|
|
|
git_footer_html();
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
sub git_commitdiff_plain {
|
|
|
|
mkdir($git_temp, 0700);
|
|
|
|
open my $fd, "-|", "$gitbin/git-diff-tree -r $hash_parent $hash" or die_error(undef, "Open failed.");
|
|
|
|
my (@difftree) = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd or die_error(undef, "Reading diff-tree failed.");
|
|
|
|
|
2005-08-07 20:28:01 +02:00
|
|
|
# try to figure out the next tag after this commit
|
|
|
|
my $tagname;
|
|
|
|
my %taghash;
|
|
|
|
my $tags = git_read_refs("refs/tags");
|
|
|
|
foreach my $entry (@$tags) {
|
|
|
|
my %tag = %$entry;
|
2005-08-07 20:28:53 +02:00
|
|
|
$taghash{$tag{'refid'}} = $tag{'name'};
|
2005-08-07 20:28:01 +02:00
|
|
|
}
|
|
|
|
open $fd, "-|", "$gitbin/git-rev-list HEAD";
|
|
|
|
while (my $commit = <$fd>) {
|
|
|
|
chomp $commit;
|
|
|
|
if ($taghash{$commit}) {
|
|
|
|
$tagname = $taghash{$commit};
|
|
|
|
}
|
|
|
|
if ($commit eq $hash) {
|
|
|
|
last;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
close $fd;
|
|
|
|
|
2005-10-17 03:27:54 +02:00
|
|
|
print $cgi->header(-type => "text/plain", -charset => 'utf-8', '-content-disposition' => "inline; filename=\"git-$hash.patch\"");
|
2005-08-07 20:27:18 +02:00
|
|
|
my %co = git_read_commit($hash);
|
|
|
|
my %ad = date_str($co{'author_epoch'}, $co{'author_tz'});
|
|
|
|
my $comment = $co{'comment'};
|
2005-08-07 20:28:01 +02:00
|
|
|
print "From: $co{'author'}\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"Date: $ad{'rfc2822'} ($ad{'tz_local'})\n".
|
2005-08-07 20:28:01 +02:00
|
|
|
"Subject: $co{'title'}\n";
|
|
|
|
if (defined $tagname) {
|
|
|
|
print "X-Git-Tag: $tagname\n";
|
|
|
|
}
|
|
|
|
print "X-Git-Url: $my_url?p=$project;a=commitdiff;h=$hash\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"\n";
|
2005-08-07 20:28:01 +02:00
|
|
|
|
2005-08-07 20:27:18 +02:00
|
|
|
foreach my $line (@$comment) {;
|
|
|
|
print " $line\n";
|
|
|
|
}
|
2005-08-07 20:28:01 +02:00
|
|
|
print "---\n\n";
|
|
|
|
|
2005-08-07 20:26:27 +02:00
|
|
|
foreach my $line (@difftree) {
|
|
|
|
$line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/;
|
|
|
|
my $from_id = $3;
|
|
|
|
my $to_id = $4;
|
|
|
|
my $status = $5;
|
|
|
|
my $file = $6;
|
2005-08-07 20:28:33 +02:00
|
|
|
if ($status eq "A") {
|
2005-08-07 20:26:27 +02:00
|
|
|
git_diff_print(undef, "/dev/null", $to_id, "b/$file", "plain");
|
|
|
|
} elsif ($status eq "D") {
|
|
|
|
git_diff_print($from_id, "a/$file", undef, "/dev/null", "plain");
|
|
|
|
} elsif ($status eq "M") {
|
|
|
|
git_diff_print($from_id, "a/$file", $to_id, "b/$file", "plain");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-08-07 20:21:23 +02:00
|
|
|
sub git_history {
|
2005-08-07 20:21:04 +02:00
|
|
|
if (!defined $hash) {
|
2005-08-07 20:23:12 +02:00
|
|
|
$hash = git_read_hash("$project/HEAD");
|
2005-08-07 20:21:23 +02:00
|
|
|
}
|
|
|
|
my %co = git_read_commit($hash);
|
|
|
|
if (!%co) {
|
|
|
|
die_error(undef, "Unknown commit object.");
|
2005-08-07 20:17:00 +02:00
|
|
|
}
|
2005-08-07 20:16:07 +02:00
|
|
|
git_header_html();
|
2005-08-07 20:21:46 +02:00
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") .
|
2005-08-07 20:21:23 +02:00
|
|
|
"<br/><br/>\n" .
|
|
|
|
"</div>\n";
|
2005-08-07 20:18:13 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:17:50 +02:00
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div class=\"page_path\"><b>/$file_name</b><br/></div>\n";
|
2005-08-07 20:25:27 +02:00
|
|
|
|
2005-11-14 06:10:07 +01:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'";
|
2005-08-07 20:21:04 +02:00
|
|
|
my $commit;
|
2005-08-07 20:25:42 +02:00
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:21:04 +02:00
|
|
|
while (my $line = <$fd>) {
|
2005-08-07 20:27:49 +02:00
|
|
|
if ($line =~ m/^([0-9a-fA-F]{40})/){
|
2005-08-07 20:21:04 +02:00
|
|
|
$commit = $1;
|
|
|
|
next;
|
2005-08-07 20:16:07 +02:00
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
if ($line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/ && (defined $commit)) {
|
2005-08-07 20:21:23 +02:00
|
|
|
my %co = git_read_commit($commit);
|
2005-08-07 20:21:04 +02:00
|
|
|
if (!%co) {
|
|
|
|
next;
|
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:25:42 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:27:27 +02:00
|
|
|
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
|
|
|
|
"<td>" . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "list"}, "<b>" .
|
|
|
|
esc_html(chop_str($co{'title'}, 50)) . "</b>") . "</td>\n" .
|
2005-08-07 20:25:27 +02:00
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;hb=$commit;f=$file_name")}, "blob");
|
2005-08-07 20:21:46 +02:00
|
|
|
my $blob = git_get_hash_by_path($hash, $file_name);
|
|
|
|
my $blob_parent = git_get_hash_by_path($commit, $file_name);
|
|
|
|
if (defined $blob && defined $blob_parent && $blob ne $blob_parent) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print " | " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=blobdiff;h=$blob;hp=$blob_parent;hb=$commit;f=$file_name")},
|
2005-08-07 20:27:18 +02:00
|
|
|
"diff to current");
|
2005-08-07 20:21:46 +02:00
|
|
|
}
|
2005-08-07 20:25:27 +02:00
|
|
|
print "</td>\n" .
|
|
|
|
"</tr>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
undef $commit;
|
2005-08-07 20:17:00 +02:00
|
|
|
}
|
2005-08-07 20:16:07 +02:00
|
|
|
}
|
2005-08-07 20:25:42 +02:00
|
|
|
print "</table>\n";
|
2005-08-07 20:21:04 +02:00
|
|
|
close $fd;
|
2005-08-07 20:16:07 +02:00
|
|
|
git_footer_html();
|
2005-08-07 19:49:46 +02:00
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
|
|
|
|
sub git_search {
|
|
|
|
if (!defined $searchtext) {
|
|
|
|
die_error("", "Text field empty.");
|
|
|
|
}
|
|
|
|
if (!defined $hash) {
|
|
|
|
$hash = git_read_hash("$project/HEAD");
|
|
|
|
}
|
|
|
|
my %co = git_read_commit($hash);
|
|
|
|
if (!%co) {
|
|
|
|
die_error(undef, "Unknown commit object.");
|
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
# pickaxe may take all resources of your box and run for several minutes
|
|
|
|
# with every query - so decide by yourself how public you make this feature :)
|
|
|
|
my $commit_search = 1;
|
|
|
|
my $author_search = 0;
|
|
|
|
my $committer_search = 0;
|
|
|
|
my $pickaxe_search = 0;
|
|
|
|
if ($searchtext =~ s/^author\\://i) {
|
|
|
|
$author_search = 1;
|
|
|
|
} elsif ($searchtext =~ s/^committer\\://i) {
|
|
|
|
$committer_search = 1;
|
|
|
|
} elsif ($searchtext =~ s/^pickaxe\\://i) {
|
|
|
|
$commit_search = 0;
|
|
|
|
$pickaxe_search = 1;
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary;h=$hash")}, "summary") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "shortlog") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$hash")}, "tree") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<br/><br/>\n" .
|
|
|
|
"</div>\n";
|
|
|
|
|
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash"), -class => "title"}, esc_html($co{'title'})) . "\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:27:18 +02:00
|
|
|
if ($commit_search) {
|
|
|
|
$/ = "\0";
|
2005-09-13 02:21:59 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list --header --parents $hash" or next;
|
2005-08-07 20:27:18 +02:00
|
|
|
while (my $commit_text = <$fd>) {
|
|
|
|
if (!grep m/$searchtext/i, $commit_text) {
|
|
|
|
next;
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
if ($author_search && !grep m/\nauthor .*$searchtext/i, $commit_text) {
|
|
|
|
next;
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
if ($committer_search && !grep m/\ncommitter .*$searchtext/i, $commit_text) {
|
2005-08-07 20:26:27 +02:00
|
|
|
next;
|
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
my @commit_lines = split "\n", $commit_text;
|
2005-09-13 02:21:59 +02:00
|
|
|
my %co = git_read_commit(undef, \@commit_lines);
|
2005-08-07 20:27:18 +02:00
|
|
|
if (!%co) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
if ($alternate) {
|
|
|
|
print "<tr class=\"dark\">\n";
|
|
|
|
} else {
|
|
|
|
print "<tr class=\"light\">\n";
|
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:27:27 +02:00
|
|
|
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$co{'id'}"), -class => "list"}, "<b>" . esc_html(chop_str($co{'title'}, 50)) . "</b><br/>");
|
2005-08-07 20:27:18 +02:00
|
|
|
my $comment = $co{'comment'};
|
|
|
|
foreach my $line (@$comment) {
|
|
|
|
if ($line =~ m/^(.*)($searchtext)(.*)$/i) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $lead = esc_html($1) || "";
|
2005-08-07 20:27:18 +02:00
|
|
|
$lead = chop_str($lead, 30, 10);
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
my $match = esc_html($2) || "";
|
|
|
|
my $trail = esc_html($3) || "";
|
2005-08-07 20:27:18 +02:00
|
|
|
$trail = chop_str($trail, 30, 10);
|
|
|
|
my $text = "$lead<span style=\"color:#e00000\">$match</span>$trail";
|
|
|
|
print chop_str($text, 80, 5) . "<br/>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$co{'id'}")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$co{'id'}")}, "tree");
|
2005-08-07 20:27:18 +02:00
|
|
|
print "</td>\n" .
|
|
|
|
"</tr>\n";
|
|
|
|
}
|
|
|
|
close $fd;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($pickaxe_search) {
|
|
|
|
$/ = "\n";
|
2005-11-14 15:15:12 +01:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin -S\'$searchtext\'";
|
2005-08-07 20:27:18 +02:00
|
|
|
undef %co;
|
|
|
|
my @files;
|
|
|
|
while (my $line = <$fd>) {
|
|
|
|
if (%co && $line =~ m/^:([0-7]{6}) ([0-7]{6}) ([0-9a-fA-F]{40}) ([0-9a-fA-F]{40}) (.)\t(.*)$/) {
|
|
|
|
my %set;
|
|
|
|
$set{'file'} = $6;
|
|
|
|
$set{'from_id'} = $3;
|
|
|
|
$set{'to_id'} = $4;
|
|
|
|
$set{'id'} = $set{'to_id'};
|
|
|
|
if ($set{'id'} =~ m/0{40}/) {
|
|
|
|
$set{'id'} = $set{'from_id'};
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
if ($set{'id'} =~ m/0{40}/) {
|
|
|
|
next;
|
|
|
|
}
|
|
|
|
push @files, \%set;
|
2005-08-12 22:12:58 +02:00
|
|
|
} elsif ($line =~ m/^([0-9a-fA-F]{40})$/){
|
2005-08-07 20:27:18 +02:00
|
|
|
if (%co) {
|
|
|
|
if ($alternate) {
|
|
|
|
print "<tr class=\"dark\">\n";
|
|
|
|
} else {
|
|
|
|
print "<tr class=\"light\">\n";
|
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:27:27 +02:00
|
|
|
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$co{'id'}"), -class => "list"}, "<b>" .
|
|
|
|
esc_html(chop_str($co{'title'}, 50)) . "</b><br/>");
|
2005-08-07 20:27:18 +02:00
|
|
|
while (my $setref = shift @files) {
|
|
|
|
my %set = %$setref;
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=blob;h=$set{'id'};hb=$co{'id'};f=$set{'file'}"), class => "list"},
|
|
|
|
"<span style=\"color:#e00000\">" . esc_html($set{'file'}) . "</span>") .
|
2005-08-07 20:27:18 +02:00
|
|
|
"<br/>\n";
|
|
|
|
}
|
|
|
|
print "</td>\n" .
|
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$co{'id'}")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$co{'tree'};hb=$co{'id'}")}, "tree");
|
2005-08-07 20:27:18 +02:00
|
|
|
print "</td>\n" .
|
|
|
|
"</tr>\n";
|
|
|
|
}
|
|
|
|
%co = git_read_commit($1);
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
close $fd;
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
|
|
|
print "</table>\n";
|
|
|
|
git_footer_html();
|
|
|
|
}
|
|
|
|
|
|
|
|
sub git_shortlog {
|
|
|
|
my $head = git_read_hash("$project/HEAD");
|
|
|
|
if (!defined $hash) {
|
|
|
|
$hash = $head;
|
|
|
|
}
|
2005-08-07 20:26:49 +02:00
|
|
|
if (!defined $page) {
|
|
|
|
$page = 0;
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
git_header_html();
|
|
|
|
print "<div class=\"page_nav\">\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary")}, "summary") .
|
2005-08-07 20:26:27 +02:00
|
|
|
" | shortlog" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=log;h=$hash")}, "log") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$hash")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$hash")}, "commitdiff") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=tree;h=$hash;hb=$hash")}, "tree") . "<br/>\n";
|
2005-08-07 20:26:49 +02:00
|
|
|
|
|
|
|
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
|
2005-08-07 20:26:27 +02:00
|
|
|
open my $fd, "-|", "$gitbin/git-rev-list $limit $hash" or die_error(undef, "Open failed.");
|
|
|
|
my (@revlist) = map { chomp; $_ } <$fd>;
|
|
|
|
close $fd;
|
2005-08-07 20:26:49 +02:00
|
|
|
|
|
|
|
if ($hash ne $head || $page) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog")}, "HEAD");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print "HEAD";
|
|
|
|
}
|
|
|
|
if ($page > 0) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print " ⋅ " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash;pg=" . ($page-1)), -accesskey => "p", -title => "Alt-p"}, "prev");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print " ⋅ prev";
|
|
|
|
}
|
|
|
|
if ($#revlist >= (100 * ($page+1)-1)) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print " ⋅ " .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash;pg=" . ($page+1)), -accesskey => "n", -title => "Alt-n"}, "next");
|
2005-08-07 20:26:49 +02:00
|
|
|
} else {
|
|
|
|
print " ⋅ next";
|
|
|
|
}
|
|
|
|
print "<br/>\n" .
|
|
|
|
"</div>\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
print "<div>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=summary"), -class => "title"}, " ") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</div>\n";
|
|
|
|
print "<table cellspacing=\"0\">\n";
|
|
|
|
my $alternate = 0;
|
2005-08-07 20:26:49 +02:00
|
|
|
for (my $i = ($page * 100); $i <= $#revlist; $i++) {
|
|
|
|
my $commit = $revlist[$i];
|
2005-08-07 20:26:27 +02:00
|
|
|
my %co = git_read_commit($commit);
|
|
|
|
my %ad = date_str($co{'author_epoch'});
|
|
|
|
if ($alternate) {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"dark\">\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
} else {
|
2005-08-07 20:27:18 +02:00
|
|
|
print "<tr class=\"light\">\n";
|
2005-08-07 20:26:27 +02:00
|
|
|
}
|
|
|
|
$alternate ^= 1;
|
2005-08-07 20:27:27 +02:00
|
|
|
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
"<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
|
2005-08-31 03:47:13 +02:00
|
|
|
"<td>";
|
|
|
|
if (length($co{'title_short'}) < length($co{'title'})) {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
|
|
|
|
"<b>" . esc_html($co{'title_short'}) . "</b>");
|
2005-08-31 03:47:13 +02:00
|
|
|
} else {
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
print $cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit"), -class => "list"},
|
|
|
|
"<b>" . esc_html($co{'title_short'}) . "</b>");
|
2005-08-31 03:47:13 +02:00
|
|
|
}
|
|
|
|
print "</td>\n" .
|
2005-08-07 20:26:27 +02:00
|
|
|
"<td class=\"link\">" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=commit;h=$commit")}, "commit") .
|
|
|
|
" | " . $cgi->a({-href => esc_url("$my_uri?p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
|
2005-08-07 20:26:27 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"</tr>";
|
|
|
|
}
|
2005-08-07 20:27:18 +02:00
|
|
|
if ($#revlist >= (100 * ($page+1)-1)) {
|
|
|
|
print "<tr>\n" .
|
|
|
|
"<td>" .
|
replace invalid utf8 sequences by UTF-8 REPLACEMENT CHARACTER (efbfbd)
I still strongly disagree with the git maintainers not to hint people,
to use the only sane default encoding for a distributed project,
which is utf8. I'm tired of hearing filesystem development arguments.
Git is a software offered to merge forth and back across the world
and not to provide a content neutral filesystem.
Btw: I have nothing against the ability to run git in a closed environment,
with a different encoding, that's fine, sure. But that is obviously not
the case for the projects on kernel.org. It's about sane defaults,
nothing else.
You have to make decisions guy, as always in life. The problems to
allow random encoded garbage in commit messages _without_ storing
the encoding, just makes zero sense. Eighter you introduce a per-commit
encoding field, if you insist on this craziness, or you define a default
encoding. Everything else is just lazy and does not solve any problem,
besides that you can claim now, that you are not responsible for the mess
in the repository.
Gitweb shows several commits at once, you allow various encodings committed
to the same repository, without any hint what that garbage from the
individual commits is encoded with. No idea why you don't get
the problem - it's unsolvable. If you merge different peoples work, you
have to speak a common language!
Kay Sievers <kay.sievers@vrfy.org>
2005-11-19 17:41:29 +01:00
|
|
|
$cgi->a({-href => esc_url("$my_uri?p=$project;a=shortlog;h=$hash;pg=" . ($page+1)), -title => "Alt-n"}, "next") .
|
2005-08-07 20:27:18 +02:00
|
|
|
"</td>\n" .
|
|
|
|
"</tr>\n";
|
|
|
|
}
|
2005-08-07 20:26:27 +02:00
|
|
|
print "</table\n>";
|
|
|
|
git_footer_html();
|
|
|
|
}
|