* [PATCH] gitweb: support perl 5.6
From: Sven Verdoolaege @ 2006-09-09 14:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Specifically, perl 5.6 doesn't have the Encode module and
doesn't support the open "-|" list form.
Signed-off-by: Sven Verdoolage <skimo@liacs.nl>
---
This is take two, hopefully addressing Jakub's remark.
gitweb/gitweb.perl | 94 +++++++++++++++++++++++++++++-----------------------
1 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d89f709..9992046 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -12,11 +12,12 @@ use warnings;
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
-use Encode;
+eval { require Encode; import Encode; };
+our $have_encode = !$@;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
-binmode STDOUT, ':utf8';
+binmode STDOUT, ':utf8' if $have_encode;
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
@@ -347,10 +348,16 @@ sub esc_param {
return $str;
}
+sub utf8_decode {
+ my $str = shift;
+ $str = decode("utf8", $str, eval "Encode::FB_DEFAULT") if $have_encode;
+ return $str;
+}
+
# replace invalid utf8 character with SUBSTITUTION sequence
sub esc_html {
my $str = shift;
- $str = decode("utf8", $str, Encode::FB_DEFAULT);
+ $str = utf8_decode($str);
$str = escapeHTML($str);
$str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
return $str;
@@ -582,6 +589,12 @@ sub git_cmd {
return $GIT, '--git-dir='.$git_dir;
}
+# returns pipe reading from git command with given arguments
+sub git_pipe {
+ open my $fd, "-|", join(' ', git_cmd(), @_) or return undef;
+ return $fd;
+}
+
# returns path to the core git executable and the --git-dir parameter as string
sub git_cmd_str {
return join(' ', git_cmd());
@@ -593,7 +606,7 @@ sub git_get_head_hash {
my $o_git_dir = $git_dir;
my $retval = undef;
$git_dir = "$projectroot/$project";
- if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
+ if (my $fd = git_pipe("rev-parse", "--verify", "HEAD")) {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
@@ -610,7 +623,7 @@ # get type of given object
sub git_get_type {
my $hash = shift;
- open my $fd, "-|", git_cmd(), "cat-file", '-t', $hash or return;
+ my $fd = git_pipe("cat-file", '-t', $hash) or return;
my $type = <$fd>;
close $fd or return;
chomp $type;
@@ -640,7 +653,7 @@ sub git_get_hash_by_path {
my $tree = $base;
- open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
+ my $fd = git_pipe("ls-tree", $base, "--", $path)
or die_error(undef, "Open git-ls-tree failed");
my $line = <$fd>;
close $fd or return undef;
@@ -719,7 +732,7 @@ sub git_get_projects_list {
if (-e "$projectroot/$path/HEAD") {
my $pr = {
path => $path,
- owner => decode("utf8", $owner, Encode::FB_DEFAULT),
+ owner => utf8_decode($owner),
};
push @list, $pr
}
@@ -748,7 +761,7 @@ sub git_get_project_owner {
$pr = unescape($pr);
$ow = unescape($ow);
if ($pr eq $project) {
- $owner = decode("utf8", $ow, Encode::FB_DEFAULT);
+ $owner = utf8_decode($ow);
last;
}
}
@@ -771,7 +784,7 @@ sub git_get_references {
open $fd, "$projectroot/$project/info/refs"
or return;
} else {
- open $fd, "-|", git_cmd(), "ls-remote", "."
+ $fd = git_pipe("ls-remote", ".")
or return;
}
@@ -792,7 +805,7 @@ sub git_get_references {
sub git_get_rev_name_tags {
my $hash = shift || return undef;
- open my $fd, "-|", git_cmd(), "name-rev", "--tags", $hash
+ my $fd = git_pipe("name-rev", "--tags", $hash)
or return;
my $name_rev = <$fd>;
close $fd;
@@ -840,7 +853,7 @@ sub parse_tag {
my %tag;
my @comment;
- open my $fd, "-|", git_cmd(), "cat-file", "tag", $tag_id or return;
+ my $fd = git_pipe("cat-file", "tag", $tag_id) or return;
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
@@ -881,7 +894,7 @@ sub parse_commit {
@commit_lines = @$commit_text;
} else {
$/ = "\0";
- open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", "--max-count=1", $commit_id
+ my $fd = git_pipe("rev-list", "--header", "--parents", "--max-count=1", $commit_id)
or return;
@commit_lines = split '\n', <$fd>;
close $fd or return;
@@ -1098,7 +1111,7 @@ sub get_file_owner {
}
my $owner = $gcos;
$owner =~ s/[,;].*$//;
- return decode("utf8", $owner, Encode::FB_DEFAULT);
+ return utf8_decode($owner);
}
## ......................................................................
@@ -2206,8 +2219,8 @@ sub git_summary {
}
print "</table>\n";
- open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
- git_get_head_hash($project)
+ my $fd = git_pipe("rev-list", "--max-count=17",
+ git_get_head_hash($project))
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2286,7 +2299,7 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ $fd = git_pipe("blame", '-l', $file_name, $hash_base)
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -2352,7 +2365,7 @@ sub git_blame {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(undef, "Error lookup file");
}
- open ($fd, "-|", git_cmd(), "annotate", '-l', '-t', '-r', $file_name, $hash_base)
+ $fd = git_pipe("annotate", '-l', '-t', '-r', $file_name, $hash_base)
or die_error(undef, "Open git-annotate failed");
git_header_html();
my $formats_nav =
@@ -2473,7 +2486,7 @@ sub git_blob_plain {
}
}
my $type = shift;
- open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
+ my $fd = git_pipe("cat-file", "blob", $hash)
or die_error(undef, "Couldn't cat $file_name, $hash");
$type ||= blob_mimetype($fd, $file_name);
@@ -2515,7 +2528,7 @@ sub git_blob {
}
}
my ($have_blame) = gitweb_check_feature('blame');
- open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
+ my $fd =git_pipe("cat-file", "blob", $hash)
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
if ($mimetype !~ m/^text\//) {
@@ -2580,7 +2593,7 @@ sub git_tree {
}
}
$/ = "\0";
- open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
+ my $fd = git_pipe("ls-tree", '-z', $hash)
or die_error(undef, "Open git-ls-tree failed");
my @entries = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading tree failed");
@@ -2666,7 +2679,7 @@ sub git_log {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
+ my $fd = git_pipe("rev-list", $limit, $hash)
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2721,7 +2734,7 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
+ my $fd = git_pipe("diff-tree", '-r', @diff_opts, $parent, $hash)
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
@@ -2828,8 +2841,8 @@ sub git_blobdiff {
if (defined $hash_base && defined $hash_parent_base) {
if (defined $file_name) {
# read raw output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base,
- "--", $file_name
+ $fd = git_pipe("diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base,
+ "--", $file_name)
or die_error(undef, "Open git-diff-tree failed");
@difftree = map { chomp; $_ } <$fd>;
close $fd
@@ -2842,7 +2855,7 @@ sub git_blobdiff {
# try to find filename from $hash
# read filtered raw output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base
+ $fd = git_pipe("diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base)
or die_error(undef, "Open git-diff-tree failed");
@difftree =
# ':100644 100644 03b21826... 3b93d5e7... M ls-files.c'
@@ -2876,9 +2889,9 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ $fd = git_pipe("diff-tree", '-r', @diff_opts,
'-p', $hash_parent_base, $hash_base,
- "--", $file_name
+ "--", $file_name)
or die_error(undef, "Open git-diff-tree failed");
}
@@ -2912,7 +2925,7 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", git_cmd(), "diff", '-p', @diff_opts, $hash_parent, $hash
+ $fd = git_pipe("diff", '-p', @diff_opts, $hash_parent, $hash)
or die_error(undef, "Open git-diff failed");
} else {
die_error('404 Not Found', "Missing one of the blob diff parameters")
@@ -2997,8 +3010,8 @@ sub git_commitdiff {
my $fd;
my @difftree;
if ($format eq 'html') {
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- "--patch-with-raw", "--full-index", $hash_parent, $hash
+ $fd = git_pipe("diff-tree", '-r', @diff_opts,
+ "--patch-with-raw", "--full-index", $hash_parent, $hash)
or die_error(undef, "Open git-diff-tree failed");
while (chomp(my $line = <$fd>)) {
@@ -3008,8 +3021,8 @@ sub git_commitdiff {
}
} elsif ($format eq 'plain') {
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- '-p', $hash_parent, $hash
+ $fd = git_pipe("diff-tree", '-r', @diff_opts,
+ '-p', $hash_parent, $hash)
or die_error(undef, "Open git-diff-tree failed");
} else {
@@ -3108,8 +3121,7 @@ sub git_history {
}
git_print_page_path($file_name, $ftype, $hash_base);
- open my $fd, "-|",
- git_cmd(), "rev-list", "--full-history", $hash_base, "--", $file_name;
+ my $fd = git_pipe("rev-list", "--full-history", $hash_base, "--", $file_name);
git_history_body($fd, $refs, $hash_base, $ftype);
@@ -3150,7 +3162,7 @@ sub git_search {
my $alternate = 0;
if ($commit_search) {
$/ = "\0";
- open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", $hash or next;
+ my $fd = git_pipe("rev-list", "--header", "--parents", $hash or next);
while (my $commit_text = <$fd>) {
if (!grep m/$searchtext/i, $commit_text) {
next;
@@ -3271,7 +3283,7 @@ sub git_shortlog {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
+ my $fd = git_pipe("rev-list", $limit, $hash)
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -3299,7 +3311,7 @@ ## feeds (RSS, OPML)
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", git_cmd(), "rev-list", "--max-count=150", git_get_head_hash($project)
+ my $fd = git_pipe("rev-list", "--max-count=150", git_get_head_hash($project))
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-rev-list failed");
@@ -3322,8 +3334,8 @@ XML
last;
}
my %cd = parse_date($co{'committer_epoch'});
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- $co{'parent'}, $co{'id'}
+ $fd = git_pipe("diff-tree", '-r', @diff_opts,
+ $co{'parent'}, $co{'id'})
or next;
my @difftree = map { chomp; $_ } <$fd>;
close $fd
@@ -3341,7 +3353,7 @@ XML
"<![CDATA[\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
- $line = decode("utf8", $line, Encode::FB_DEFAULT);
+ $line = utf8_decode($line);
print "$line<br/>\n";
}
print "<br/>\n";
@@ -3350,7 +3362,7 @@ XML
next;
}
my $file = validate_input(unquote($7));
- $file = decode("utf8", $file, Encode::FB_DEFAULT);
+ $file = utf8_decode($file);
print "$file<br/>\n";
}
print "]]>\n" .
--
0.99.8c.g64e8-dirty
^ permalink raw reply related
* Re: [PATCH 2/4] git-archive: wire up TAR format.
From: Franck Bui-Huu @ 2006-09-09 14:38 UTC (permalink / raw)
To: Rene Scharfe; +Cc: junkio, git
In-Reply-To: <4501D0CF.70306@lsrfire.ath.cx>
2006/9/8, Rene Scharfe <rene.scharfe@lsrfire.ath.cx>:
> Franck Bui-Huu schrieb:
> > From: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> >
> > Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> > Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
>
> I did not sign off this exact patch. I wrote and submitted the
> builtin-tar-tree.c part, with memory leak and all, then sent a note
> on where the leak needs to be plugged. You put it together and
> converted it to struct archiver_args. I'd very much have liked to
> see a comment stating this. Or simply just say "based on code by
> Rene" or something. The same is true for patch 3/4.
>
OK I'll change that....
> > ---
> > extern void parse_pathspec_arg(const char **pathspec,
> > struct archiver_args *args);
> > +/*
> > + *
> > + */
>
> Especially I would not have signed off this invisible comment. ;)
>
> René
>
and put something usefull here.
Thanks
--
Franck
^ permalink raw reply
* Re: [PATCH 1/4] Add git-archive
From: Franck Bui-Huu @ 2006-09-09 14:31 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <4501D0C5.702@lsrfire.ath.cx>
2006/9/8, Rene Scharfe <rene.scharfe@lsrfire.ath.cx>:
> Only a few trivial comments, as I managed to catch a cold somehow and
> can't think straight for longer than three seconds.
>
> > .gitignore | 1
> > Documentation/git-archive.txt | 100 ++++++++++++++++++
> > Makefile | 3 -
[snip]
> > +
> > + url = strdup(ar->remote);
>
> xstrdup()
>
ok, but need to rebase...
> > + pid = git_connect(fd, url, buf);
> > + if (pid < 0)
> > + return pid;
> > +
[snip]
> > + int extra_argc = 0;
> > + const char *format = NULL; /* some default values */
>
> This comment does not convey any information.
>
OK, I'll remove it
> > + const char *remote = NULL;
> > + const char *base = "";
[snip]
> > + }
> > + if (arg[0] == '-') {
> > + extra_argv[extra_argc++] = arg;
>
> Overrun is not checked.
>
Indeed, I'll fix it.
> > + continue;
> > + }
> > + break;
> > + }
> > + if (list) {
> > + if (!remote) {
> > + for (i = 0; i < ARRAY_SIZE(archivers); i++)
> > + printf("%s\n", archivers[i].name);
> > + exit(0);
> > + }
> > + die("--list and --remote are mutually exclusive");
> > + }
>
> Not sure if we really need a list option. I guess it only really
> makes sense if we have more than five formats. I have no _strong_
> feelings against it, though. *shrug*
>
well it's almost free to add it, and no need any maintenance if we add
a new archiver backend, so I would say let it.
> > + if (argc - i < 1) {
> > + die("%s", archive_usage);
>
> usage()
>
ok
--
Franck
^ permalink raw reply
* [ANNOUNCE qgit-1.5]
From: Marco Costalba @ 2006-09-09 13:23 UTC (permalink / raw)
To: Git Mailing List, linux-kernel
This is qgit-1.5
With qgit you will be able to browse revision histories, view patch content
and changed files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- Associate commands sequences, scripts and anything else executable
to a custom action. Actions can be run from menu and corresponding
output is grabbed by a terminal window.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
Multi tab support and source highlighter are the cool new features.
Multi tab allows the user to open many patch or file view tabs, each
linked on a different revision.
If GNU Source-highlight (http://www.gnu.org/software/src-highlite/) is
installed and in PATH then it is possible to toggle source code highlight
pressing the Color text tool button in file viewer. Please refer to
Source-highlight site for the list of supported languages and additional
documentation.
Some bugs squashed too. Not a lot though...qgit-1.4 has been a
very stable release ;-)
Finally, some performance tweaking.
Please note that you will need git 1.4.0 or newer.
DOWNLOAD
Tarball is
http://prdownloads.sourceforge.net/qgit/qgit-1.5.tar.bz2?download
Git archive is
git://git.kernel.org/pub/scm/qgit/qgit.git
See http://digilander.libero.it/mcostalba/ for detailed download information.
INSTALLATION
git 1.4.0 or better is required.
To install from tarball:
./configure
make
make install-strip
To install from git archive:
autoreconf -i
./configure
make
make install-strip
Or check the shipped README for detailed information.
CHANGELOG from 1.4
- use GNU Source-highlight external tool with file viewer
- show file rename/copy info on patch and file list views
- show the currently checked-out head in bold font
- show stat info at the beginning of patch view also for merges
- added support for multi tab patch viewers aka 'view patch in a new tab'
- added support for multi tab file viewers aka 'view file in a new tab'
- improve size compression of revision's files saved data
- disable 'close tab' button if current tab is the main view
- replace "git-" commands with "git ". Most git commands are now built-in
- other small fixes and some performance tweaks
For a complete changelog see shipped ChangeLog file or git repository
revision's history
Marco
^ permalink raw reply
* Re: Change set based shallow clone
From: Marco Costalba @ 2006-09-09 13:00 UTC (permalink / raw)
To: linux@horizon.com; +Cc: git
In-Reply-To: <20060909103157.23388.qmail@science.horizon.com>
On 9 Sep 2006 06:31:57 -0400, linux@horizon.com <linux@horizon.com> wrote:
> > If the out of order revisions are a small amount of the total then
> > could be possible to have something like
> >
> > git rev-list --topo-order --with-appended-fixups HEAD
> >
> > Where, while git-rev-list is working _whithout sorting the whole tree
> > first_, when finds an out of order revision stores it in a fixup-list
> > buffer and *at the end* of normal git-rev-lsit the buffer is flushed
> > to receiver, so that the drawing logic does not change and the out of
> > order revisions arrive at the end, already packed, sorted and prepared
> > by git-rev-list.
>
> I don't think I understand your proposal. The problem arises when
> git-rev-list finds a commit that it should have listed before something
> that it has already output.
>
> Just for example:
>
> Commit D: Ancestor B
> Commit B: Ancestor A
> Commit C: Ancestor B
>
> Commit C is the problem, because if git-rev-list has already output B,
> there's no way to back up and insert it in the right place.
>
> How is waiting to output the already-behind-schedule commit C going
> to help anything?
It helps in a number of ways from receiver point of view.
- Receiver doesn't need to keep a sorted list of loaded revisions.
- Receiver doesn't need to stop parsing input and redraw the graph in
the middle of the loading.
- Receiver doesn't need to check for possible out of order commits
when loading data, but can be assured data that arrives is
--topo-order consistent (although my not be complete)
- Split the in order parsing code (performance critical and common
case) from fixup-code (run at the end and on a small set of commits).
- Much faster implementation because the sorting is done only in
git-rev-list and only once.
Following your example my suggestion was something like this:
Instead of:
git-rev-list HEAD
Commit D: Ancestor B
Commit B: Ancestor A
Commit C: Ancestor B
Commit A: Ancestor E
Commit E: Ancestor F
Commit F: Ancestor G
....
Commit V: Ancestor Z
git-rev-list --topo-order ----with-appended-fixups HEAD
sends something like:
Commit D: Ancestor B
Commit B: Ancestor A
Commit A: Ancestor E
Commit E: Ancestor F
Commit F: Ancestor G
....
Commit V: Ancestor Z
(* end of correct sorted commits and start of out of order commits*)
Commit C: Ancestor B
......
Commit N: Ancestor M
So that receiver drawing code designed with working with --topo-order
kind output could as usual draws the graph until Commit V: Ancestor Z
(but without waiting for git-rev-list latency!!) and the new fixup
code could *at the end* loop across *already sorted* fixup set:
Commit C: Ancestor B
......
Commit N: Ancestor M
and update the graph in one go. Of course some flag/syntax should be
introduced to trigger the end of sorted code and beginning of fixups
in git-rev-list output stream.
Marco
^ permalink raw reply
* Re: [PATCH] gitweb: support perl 5.6
From: Jakub Narebski @ 2006-09-09 12:19 UTC (permalink / raw)
To: git
In-Reply-To: <20060909104605.GA22331@liacs.nl>
Sven Verdoolaege wrote:
> Specifically, perl 5.6 doesn't have the Encode module and
> doesn't support the open "-|" list form.
The way to remove requirement of Encode module is done nice.
Changing open "-|" list form back to the 3-arg form -- it would
be better IMVHO to refactor this into git_pipe or similar function.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: support perl 5.6
From: Sven Verdoolaege @ 2006-09-09 10:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
Specifically, perl 5.6 doesn't have the Encode module and
doesn't support the open "-|" list form.
Signed-off-by: Sven Verdoolage <skimo@liacs.nl>
---
gitweb/gitweb.perl | 115 +++++++++++++++++++++++++++++++++-------------------
1 files changed, 74 insertions(+), 41 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d89f709..c1ee15e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -12,11 +12,12 @@ use warnings;
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
-use Encode;
+eval { require Encode; import Encode; };
+our $have_encode = !$@;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
-binmode STDOUT, ':utf8';
+binmode STDOUT, ':utf8' if $have_encode;
our $cgi = new CGI;
our $version = "++GIT_VERSION++";
@@ -347,10 +348,16 @@ sub esc_param {
return $str;
}
+sub utf8_decode {
+ my $str = shift;
+ $str = decode("utf8", $str, eval "Encode::FB_DEFAULT") if $have_encode;
+ return $str;
+}
+
# replace invalid utf8 character with SUBSTITUTION sequence
sub esc_html {
my $str = shift;
- $str = decode("utf8", $str, Encode::FB_DEFAULT);
+ $str = utf8_decode($str);
$str = escapeHTML($str);
$str =~ s/\014/^L/g; # escape FORM FEED (FF) character (e.g. in COPYING file)
return $str;
@@ -593,7 +600,8 @@ sub git_get_head_hash {
my $o_git_dir = $git_dir;
my $retval = undef;
$git_dir = "$projectroot/$project";
- if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
+ my $git_command = git_cmd_str();
+ if (open my $fd, "-|", "$git_command rev-parse --verify HEAD") {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
@@ -610,7 +618,8 @@ # get type of given object
sub git_get_type {
my $hash = shift;
- open my $fd, "-|", git_cmd(), "cat-file", '-t', $hash or return;
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file -t $hash" or return;
my $type = <$fd>;
close $fd or return;
chomp $type;
@@ -640,7 +649,8 @@ sub git_get_hash_by_path {
my $tree = $base;
- open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command ls-tree $base -- $path"
or die_error(undef, "Open git-ls-tree failed");
my $line = <$fd>;
close $fd or return undef;
@@ -719,7 +729,7 @@ sub git_get_projects_list {
if (-e "$projectroot/$path/HEAD") {
my $pr = {
path => $path,
- owner => decode("utf8", $owner, Encode::FB_DEFAULT),
+ owner => utf8_decode($owner),
};
push @list, $pr
}
@@ -748,7 +758,7 @@ sub git_get_project_owner {
$pr = unescape($pr);
$ow = unescape($ow);
if ($pr eq $project) {
- $owner = decode("utf8", $ow, Encode::FB_DEFAULT);
+ $owner = utf8_decode($ow);
last;
}
}
@@ -771,7 +781,8 @@ sub git_get_references {
open $fd, "$projectroot/$project/info/refs"
or return;
} else {
- open $fd, "-|", git_cmd(), "ls-remote", "."
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command ls-remote ."
or return;
}
@@ -792,7 +803,8 @@ sub git_get_references {
sub git_get_rev_name_tags {
my $hash = shift || return undef;
- open my $fd, "-|", git_cmd(), "name-rev", "--tags", $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command name-rev --tags $hash"
or return;
my $name_rev = <$fd>;
close $fd;
@@ -840,7 +852,8 @@ sub parse_tag {
my %tag;
my @comment;
- open my $fd, "-|", git_cmd(), "cat-file", "tag", $tag_id or return;
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file tag $tag_id" or return;
$tag{'id'} = $tag_id;
while (my $line = <$fd>) {
chomp $line;
@@ -881,7 +894,8 @@ sub parse_commit {
@commit_lines = @$commit_text;
} else {
$/ = "\0";
- open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", "--max-count=1", $commit_id
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command rev-list --header --parents --max-count=1 $commit_id"
or return;
@commit_lines = split '\n', <$fd>;
close $fd or return;
@@ -1098,7 +1112,7 @@ sub get_file_owner {
}
my $owner = $gcos;
$owner =~ s/[,;].*$//;
- return decode("utf8", $owner, Encode::FB_DEFAULT);
+ return utf8_decode($owner);
}
## ......................................................................
@@ -2206,8 +2220,9 @@ sub git_summary {
}
print "</table>\n";
- open my $fd, "-|", git_cmd(), "rev-list", "--max-count=17",
- git_get_head_hash($project)
+ my $git_command = git_cmd_str();
+ my $head = git_get_head_hash($project);
+ open my $fd, "-|", "$git_command rev-list --max-count=17 $head",
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2286,7 +2301,8 @@ sub git_blame2 {
if ($ftype !~ "blob") {
die_error("400 Bad Request", "Object is not a blob");
}
- open ($fd, "-|", git_cmd(), "blame", '-l', $file_name, $hash_base)
+ my $git_command = git_cmd_str();
+ open ($fd, "-|", "$git_command blame -l $file_name $hash_base")
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
@@ -2352,7 +2368,8 @@ sub git_blame {
$hash = git_get_hash_by_path($hash_base, $file_name, "blob")
or die_error(undef, "Error lookup file");
}
- open ($fd, "-|", git_cmd(), "annotate", '-l', '-t', '-r', $file_name, $hash_base)
+ my $git_command = git_cmd_str();
+ open ($fd, "-|", "$git_command annotate -l -t -r $file_name $hash_base")
or die_error(undef, "Open git-annotate failed");
git_header_html();
my $formats_nav =
@@ -2473,7 +2490,8 @@ sub git_blob_plain {
}
}
my $type = shift;
- open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file blob $hash"
or die_error(undef, "Couldn't cat $file_name, $hash");
$type ||= blob_mimetype($fd, $file_name);
@@ -2515,7 +2533,8 @@ sub git_blob {
}
}
my ($have_blame) = gitweb_check_feature('blame');
- open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command cat-file blob $hash"
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
if ($mimetype !~ m/^text\//) {
@@ -2580,7 +2599,8 @@ sub git_tree {
}
}
$/ = "\0";
- open my $fd, "-|", git_cmd(), "ls-tree", '-z', $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command ls-tree -z $hash"
or die_error(undef, "Open git-ls-tree failed");
my @entries = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading tree failed");
@@ -2666,7 +2686,8 @@ sub git_log {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command rev-list $limit $hash"
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -2721,7 +2742,8 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command diff-tree -r @diff_opts $parent $hash"
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
@@ -2828,8 +2850,8 @@ sub git_blobdiff {
if (defined $hash_base && defined $hash_parent_base) {
if (defined $file_name) {
# read raw output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base,
- "--", $file_name
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts $hash_parent_base $hash_base -- $file_name"
or die_error(undef, "Open git-diff-tree failed");
@difftree = map { chomp; $_ } <$fd>;
close $fd
@@ -2842,7 +2864,8 @@ sub git_blobdiff {
# try to find filename from $hash
# read filtered raw output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $hash_parent_base, $hash_base
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts $hash_parent_base $hash_base"
or die_error(undef, "Open git-diff-tree failed");
@difftree =
# ':100644 100644 03b21826... 3b93d5e7... M ls-files.c'
@@ -2876,9 +2899,10 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- '-p', $hash_parent_base, $hash_base,
- "--", $file_name
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts ".
+ "-p $hash_parent_base $hash_base ".
+ "-- $file_name"
or die_error(undef, "Open git-diff-tree failed");
}
@@ -2912,7 +2936,8 @@ sub git_blobdiff {
}
# open patch output
- open $fd, "-|", git_cmd(), "diff", '-p', @diff_opts, $hash_parent, $hash
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff -p @diff_opts $hash_parent $hash"
or die_error(undef, "Open git-diff failed");
} else {
die_error('404 Not Found', "Missing one of the blob diff parameters")
@@ -2997,8 +3022,9 @@ sub git_commitdiff {
my $fd;
my @difftree;
if ($format eq 'html') {
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- "--patch-with-raw", "--full-index", $hash_parent, $hash
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts ".
+ "--patch-with-raw --full-index $hash_parent $hash"
or die_error(undef, "Open git-diff-tree failed");
while (chomp(my $line = <$fd>)) {
@@ -3008,8 +3034,9 @@ sub git_commitdiff {
}
} elsif ($format eq 'plain') {
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- '-p', $hash_parent, $hash
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts ".
+ "-p $hash_parent $hash"
or die_error(undef, "Open git-diff-tree failed");
} else {
@@ -3108,8 +3135,9 @@ sub git_history {
}
git_print_page_path($file_name, $ftype, $hash_base);
+ my $git_command = git_cmd_str();
open my $fd, "-|",
- git_cmd(), "rev-list", "--full-history", $hash_base, "--", $file_name;
+ "$git_command rev-list --full-history $hash_base -- $file_name";
git_history_body($fd, $refs, $hash_base, $ftype);
@@ -3150,7 +3178,8 @@ sub git_search {
my $alternate = 0;
if ($commit_search) {
$/ = "\0";
- open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", $hash or next;
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command rev-list --header --parents $hash" or next;
while (my $commit_text = <$fd>) {
if (!grep m/$searchtext/i, $commit_text) {
next;
@@ -3271,7 +3300,8 @@ sub git_shortlog {
my $refs = git_get_references();
my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
- open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
+ my $git_command = git_cmd_str();
+ open my $fd, "-|", "$git_command rev-list $limit $hash"
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
@@ -3299,7 +3329,9 @@ ## feeds (RSS, OPML)
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", git_cmd(), "rev-list", "--max-count=150", git_get_head_hash($project)
+ my $git_command = git_cmd_str();
+ my $head = git_get_head_hash($project);
+ open my $fd, "-|", "$git_command rev-list --max-count=150 $head"
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-rev-list failed");
@@ -3322,8 +3354,9 @@ XML
last;
}
my %cd = parse_date($co{'committer_epoch'});
- open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
- $co{'parent'}, $co{'id'}
+ my $git_command = git_cmd_str();
+ open $fd, "-|", "$git_command diff-tree -r @diff_opts ".
+ "$co{'parent'} $co{'id'}"
or next;
my @difftree = map { chomp; $_ } <$fd>;
close $fd
@@ -3341,7 +3374,7 @@ XML
"<![CDATA[\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
- $line = decode("utf8", $line, Encode::FB_DEFAULT);
+ $line = utf8_decode($line);
print "$line<br/>\n";
}
print "<br/>\n";
@@ -3350,7 +3383,7 @@ XML
next;
}
my $file = validate_input(unquote($7));
- $file = decode("utf8", $file, Encode::FB_DEFAULT);
+ $file = utf8_decode($file);
print "$file<br/>\n";
}
print "]]>\n" .
--
0.99.8c.g64e8-dirty
^ permalink raw reply related
* Re: Change set based shallow clone
From: linux @ 2006-09-09 10:31 UTC (permalink / raw)
To: mcostalba; +Cc: git, linux
> If the out of order revisions are a small amount of the total then
> could be possible to have something like
>
> git rev-list --topo-order --with-appended-fixups HEAD
>
> Where, while git-rev-list is working _whithout sorting the whole tree
> first_, when finds an out of order revision stores it in a fixup-list
> buffer and *at the end* of normal git-rev-lsit the buffer is flushed
> to receiver, so that the drawing logic does not change and the out of
> order revisions arrive at the end, already packed, sorted and prepared
> by git-rev-list.
I don't think I understand your proposal. The problem arises when
git-rev-list finds a commit that it should have listed before something
that it has already output.
Just for example:
Commit D: Ancestor B
Commit B: Ancestor A
Commit C: Ancestor B
Commit C is the problem, because if git-rev-list has already output B,
there's no way to back up and insert it in the right place.
How is waiting to output the already-behind-schedule commit C going
to help anything? The idea in gitk is to rewind the layout algorithm
to before B was added, insert C, and replay from there. This is
most efficient if C is encountered as soon after its correct place
as possible.
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Junio C Hamano @ 2006-09-09 9:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edu180$vvs$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> By the way, what do you all do with the "failed experiments", to have them
> saved somewhere, but to not make trouble for normal operations?
I usually keep them under .git/refs/tags/hold/. Yesterday (as I
said in another thread) I dropped the 64-bit packfile index
topic I had in jc/pack-toc topic from "pu" by:
git tag hold/jc/pack-toc jc/pack-toc
git branch -D jc/pack-toc
to shelve it and kill it.
In theory, I should occasionally come back to them and see if
they are worth keeping, but in practice they just keep piling up
X-<. I should find time to clean them up.
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Jakub Narebski @ 2006-09-09 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vvenxwglc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Jakub Narebski wrote:
>>
>>> Shortlog:
>>> [PATCH 1/7] gitweb: Make pickaxe search a feature
>>> [PATCH 2/7] gitweb: Paginate history output
>>> [PATCH 3/7] gitweb: Use @hist_opts as git-rev-list parameters
>>> in git_history
>>> [PATCH 4/7] gitweb: Add parse_rev_list for later use
>>> [PATCH 5/7] gitweb: Use parse_rev_list in git_shortlog and git_history
>>> [PATCH 6/7] gitweb: Assume parsed revision list in git_shortlog_body
>>> and git_history_body
>>> [PATCH 7/7] gitweb: Set page to 0 if it is not defined, in git_history
> I do not know about 4, 5 and 6. I didn't look at them at all
> the first time you sent them out, since I got an impression that
> you did not understand how git-rev-list was supposed to work
> when you did them.
>
> Now Linus explained it to you, I suspect they would probably
> need to be rethought?
Well, first they don't offer that much of speed improvement even for the
first page of output. And probably would be slower than current
implementation for the next-to-last, or the last page. So yes, patches 4-6
are to be rethought, if not dropped at all.
By the way, what do you all do with the "failed experiments", to have them
saved somewhere, but to not make trouble for normal operations?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Junio C Hamano @ 2006-09-09 9:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edtuot$p76$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>
>> Shortlog:
>> [PATCH 1/7] gitweb: Make pickaxe search a feature
>> [PATCH 2/7] gitweb: Paginate history output
>> [PATCH 3/7] gitweb: Use @hist_opts as git-rev-list parameters
>> in git_history
>> [PATCH 4/7] gitweb: Add parse_rev_list for later use
>> [PATCH 5/7] gitweb: Use parse_rev_list in git_shortlog and git_history
>> [PATCH 6/7] gitweb: Assume parsed revision list in git_shortlog_body
>> and git_history_body
>> [PATCH 7/7] gitweb: Set page to 0 if it is not defined, in git_history
>
> Should I resend corrected patch 1 (Make pickaxe search a feature; but
> default to on), and patches 2 and 7 as one patch (Paginate history output)?
I looked at and understood 1 and 2+7, although I cannot claim I
looked at 2+7 deeply enough; cursory look told me they should be
Ok. So is 3, but I suspect gitweb without --full-history might
surprise some users.
I do not know about 4, 5 and 6. I didn't look at them at all
the first time you sent them out, since I got an impression that
you did not understand how git-rev-list was supposed to work
when you did them.
Now Linus explained it to you, I suspect they would probably
need to be rethought?
^ permalink raw reply
* Re: Change set based shallow clone
From: Marco Costalba @ 2006-09-09 8:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Mackerras, Jon Smirl, linux@horizon.com, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609082054560.27779@g5.osdl.org>
On 9/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> In contrast, doing some of the same sorting that git-rev-list already does
> in the consumer instead, is obviously duplicating the same basic notions,
> but once you do it in the consumer, you can suddenly do things that simply
> weren't possible in git-rev-list - do things incrementally, and then if
> you notice half-way that you did something wrong, you can go back and fix
> it up (which can be quite acceptable). That just isn't an option in a
> linear environment like the git-rev-list output.
>
Perhaps is total idiocy but why do not implement the fix-up logic
directly in git-rev-list?
If the out of order revisions are a small amount of the total then
could be possible to have something like
git rev-list --topo-order --with-appended-fixups HEAD
Where, while git-rev-list is working _whithout sorting the whole tree
first_, when finds an out of order revision stores it in a fixup-list
buffer and *at the end* of normal git-rev-lsit the buffer is flushed
to receiver, so that the drawing logic does not change and the out of
order revisions arrive at the end, already packed, sorted and prepared
by git-rev-list.
Instead of changing drwing logic is then enough to add a fixup
routine that cycles through out of order commits and updates the
graph.
This also avoids recursive reordering where perhaps the same part of
a graph should be redrawn more then one time due to differtent new
parents to the same child arrives at different times.
Marco
^ permalink raw reply
* Re: [PATCH 0/7] gitweb: Trying to improve history view speed
From: Jakub Narebski @ 2006-09-09 8:42 UTC (permalink / raw)
To: git
In-Reply-To: <200609061504.40725.jnareb@gmail.com>
<opublikowany i wysłany>
Jakub Narebski wrote:
> Shortlog:
> [PATCH 1/7] gitweb: Make pickaxe search a feature
> [PATCH 2/7] gitweb: Paginate history output
> [PATCH 3/7] gitweb: Use @hist_opts as git-rev-list parameters
> in git_history
> [PATCH 4/7] gitweb: Add parse_rev_list for later use
> [PATCH 5/7] gitweb: Use parse_rev_list in git_shortlog and git_history
> [PATCH 6/7] gitweb: Assume parsed revision list in git_shortlog_body
> and git_history_body
> [PATCH 7/7] gitweb: Set page to 0 if it is not defined, in git_history
Should I resend corrected patch 1 (Make pickaxe search a feature; but
default to on), and patches 2 and 7 as one patch (Paginate history output)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Change set based shallow clone
From: Jakub Narebski @ 2006-09-09 8:39 UTC (permalink / raw)
To: git
In-Reply-To: <20060909031307.GE23891@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Fri, Sep 08, 2006 at 05:50:40PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> My idea for lazy clone/fetch (lazy = on-demand) is via remote alternatives
>> mechanism. We put URI for repository (repositories) that hosts the project,
>> and we would need at start to download at least heads and tags, and only
>> heads and tags.
>
> One thing to note is that you won't last very long without getting
> at least basically all the commits from the history. git log, git
> merge-base and such would either just suck them all, get partially moved
> to the server side, or would undergo quite a painful and slooooooooow
> process "get me commit X... thank you, sir. hmm, it appears that its
> parent is commit Y. could you get me commit Y, please...? thank you,
> sir. hmm, it appears...".
As I said there is load of troubles with lazy clone/fetch = remote
alternatives I didn't thought about.
git log/git rev-list and git fsck-objects among them.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Some issues with current qgit on exit ( aka "Crash this!" )
From: Marco Costalba @ 2006-09-09 8:16 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1157757903.9088.14.camel@dv>
>
> However, qgit has produced some output you may find interesting:
>
> [proski@dv qgit]$ qgit
> ASSERT in lookupAnnotation: no annotation for src/git_startup.cpp
> ASSERT in lookupAnnotation: no annotation for src/fileview.cpp
> ASSERT in lookupAnnotation: no annotation for src/git.cpp
> ASSERT in lookupAnnotation: no annotation for src/mainbase.ui
> [proski@dv qgit]$
>
It was a little regression from recent changes. Luckily much more easy
then previous one.
Logic fixed and patch pushed.
Thanks
Marco
^ permalink raw reply
* Re: Change set based shallow clone
From: Linus Torvalds @ 2006-09-09 4:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Jon Smirl, linux@horizon.com, Git Mailing List
In-Reply-To: <17666.13716.401727.601933@cargo.ozlabs.ibm.com>
On Sat, 9 Sep 2006, Paul Mackerras wrote:
>
> > The menu would help, of course. But it would be even nicer if you'd be
> > able to make do without the --topo-order.
>
> The graph does seem to look a little nicer with --topo-order, in that
> it tends to do a whole string of commits on a single branch in a
> bunch, whereas without --topo-order it seems to hop from branch to
> branch more.
Yeah, see "--date-order". It's topologically sorted, but within that
topological sort it is in the "date order", which approximates the normal
non-sorted output.
Without sorting, you also won't see any sorting by branch, although it
could be done by the consumer of the rev-list data (ie you could do it in
gitk, similarly to how you'd effectively do a topological sort of your
own).
So it actually boils down to the exact same thing:
- git-rev-list doing whatever sorting is "convenient", in that it's the
one common interface to git revisions, so once you do it there, you do
it for everybody.
- however, for much the same reason, git-rev-list by definition doesn't
know _who_ it is sorting things for, or how it's going to be visualized
(exactly because it's the "one convenient central place", of course),
and as a result it needs to not only get the right answer, it needs to
get it on the first try and can't go back incrementally to fix up the
list of commits.
So the convenience of doing any kind of sorting in git-rev-list is by
definition also the thing that causes it to have bad latency, in that it
needs to parse the _whole_ history.
In contrast, doing some of the same sorting that git-rev-list already does
in the consumer instead, is obviously duplicating the same basic notions,
but once you do it in the consumer, you can suddenly do things that simply
weren't possible in git-rev-list - do things incrementally, and then if
you notice half-way that you did something wrong, you can go back and fix
it up (which can be quite acceptable). That just isn't an option in a
linear environment like the git-rev-list output.
Linus
^ permalink raw reply
* Re: Change set based shallow clone
From: Paul Mackerras @ 2006-09-09 3:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, linux@horizon.com, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609081944060.27779@g5.osdl.org>
Linus Torvalds writes:
> Right. This is why I would suggest just recomputing the thing entirely,
> instead of trying to make it incremental. It would definitely cause
> re-organization of the tree when you find a new relationship between two
> old commits that basically creates a new orderign between them.
I think it may be possible to back up the layout algorithm to the row
where the parent is and redo it from there down.
Interestingly, I only see two commits out of order on the linux-2.6
repository, but on the full history (up to linux-2.6.12-rc2) I see
520.
> The menu would help, of course. But it would be even nicer if you'd be
> able to make do without the --topo-order.
The graph does seem to look a little nicer with --topo-order, in that
it tends to do a whole string of commits on a single branch in a
bunch, whereas without --topo-order it seems to hop from branch to
branch more.
Paul.
^ permalink raw reply
* Re: Change set based shallow clone
From: Junio C Hamano @ 2006-09-09 3:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609081944060.27779@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And the "fully packed" part is probably the most important part. A packed
> Linux historic tree takes just under six seconds cold-cache and under two
> seconds hot-cache, but that's because pack-files are _really_ good at
> mapping all the commits in just one go, and at the beginning of the
> pack-file.
>
> But try the same thing with a fully unpacked kernel, and you'll see the
> real pain of having to traverse all of history. We're talking minutes,
> even when hot in the cache.
Just a random thought... Does that suggest the general purpose
filesystem you would use for "a fully unpacked" case have room
for improvements? Would a special purpose filesystem that is
designed to host .git/objects/??/ directory help?
^ permalink raw reply
* Re: Change set based shallow clone
From: Petr Baudis @ 2006-09-09 3:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eds3fg$u30$1@sea.gmane.org>
Dear diary, on Fri, Sep 08, 2006 at 05:50:40PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> My idea for lazy clone/fetch (lazy = on-demand) is via remote alternatives
> mechanism. We put URI for repository (repositories) that hosts the project,
> and we would need at start to download at least heads and tags, and only
> heads and tags.
One thing to note is that you won't last very long without getting
at least basically all the commits from the history. git log, git
merge-base and such would either just suck them all, get partially moved
to the server side, or would undergo quite a painful and slooooooooow
process "get me commit X... thank you, sir. hmm, it appears that its
parent is commit Y. could you get me commit Y, please...? thank you,
sir. hmm, it appears...".
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Change set based shallow clone
From: Linus Torvalds @ 2006-09-09 2:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Jon Smirl, linux@horizon.com, Git Mailing List
In-Reply-To: <17666.4936.894588.825011@cargo.ozlabs.ibm.com>
On Sat, 9 Sep 2006, Paul Mackerras wrote:
>
> It might get nasty if we have laid out A and then later B, and then C
> comes along and turns out to be a child of A but a parent of B,
> meaning that both B and C have to be put above A.
Right. This is why I would suggest just recomputing the thing entirely,
instead of trying to make it incremental. It would definitely cause
re-organization of the tree when you find a new relationship between two
old commits that basically creates a new orderign between them.
Trying to do that incrementally sounds really really hard. But just
_detecting_ the situation that you are getting a new commit that has a
parent that you have already shown (and that thus must go _before_ one of
the things you've shown already, and implies a new line reacing it) is
very easy. And then re-generating the graph might not be too bad.
Running "gitk" on the kernel with a hot cache and fully packed (and enough
memory) isn't too bad, because git rev-list literally takes under a second
for that case, so the advantage of avoiding --topo-order isn't _that_
noticeable.
And the "fully packed" part is probably the most important part. A packed
Linux historic tree takes just under six seconds cold-cache and under two
seconds hot-cache, but that's because pack-files are _really_ good at
mapping all the commits in just one go, and at the beginning of the
pack-file.
But try the same thing with a fully unpacked kernel, and you'll see the
real pain of having to traverse all of history. We're talking minutes,
even when hot in the cache.
> Another thing I have been thinking of is that gitk probably should
> impose a time limit of say 3 months by default
I don't think time is good, because for an old project (like the Linux
historic repo), three months is literally nothing. So it would be much
better to go simply by numbers, but sadly, that won't help - simply
because if we want to know the 100 first commits in --topo-order, we'll do
the whole history and sort it _first_, and then do the "pick top 100
commits" only after that.
(Which may not be sensible, of course, but it's what we do.. It's almost
impossible to do it the other way, because you won't know until the point
where you do "get_revision()" if you are _actually_ going to use a commit
or not, so counting them before the end is fundamentally very hard).
> Together with a menu to select the time limit, I think that would be
> quite usable and would make gitk start up *much* faster.
The menu would help, of course. But it would be even nicer if you'd be
able to make do without the --topo-order.
Linus
^ permalink raw reply
* Re: [PATCH 2/4] git-archive: wire up TAR format.
From: Junio C Hamano @ 2006-09-09 1:53 UTC (permalink / raw)
To: Franck Bui-Huu, Rene Scharfe; +Cc: git
In-Reply-To: <7vlkouf32i.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> I did not sign off this exact patch. I wrote and submitted the
>> builtin-tar-tree.c part, with memory leak and all, then sent a note
>> on where the leak needs to be plugged. You put it together and
>> converted it to struct archiver_args. I'd very much have liked to
>> see a comment stating this. Or simply just say "based on code by
>> Rene" or something. The same is true for patch 3/4.
>>...
>> Especially I would not have signed off this invisible comment. ;)
>
> I take your response is a mild NAK.
Just to reduce everybody's pain, why don't I fix them up and
push out the 4 series in "pu" with attribution clarification and
review comments from Rene in mind, so that you two can Ack them?
After that they will be placed on "next".
I needed to apply small tweaks on 1/4 (ANSI-C pedantic did not
like empty struct initializers) and 4/4 (the updated 1/1 needed
the way struct archiver is initialized and used be different
from the original one) as well.
^ permalink raw reply
* Re: Change set based shallow clone
From: Jon Smirl @ 2006-09-09 1:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, linux@horizon.com, Git Mailing List
In-Reply-To: <17666.142.886652.667529@cargo.ozlabs.ibm.com>
On 9/8/06, Paul Mackerras <paulus@samba.org> wrote:
> Jon Smirl writes:
>
> > gitk takes about a minute to come up on the Mozilla repo when
> > everything is in cache. It takes about twice as long when things are
> > cold. It's enough of delay that I don't use the tool.
>
> How long does it take for git rev-list --topo-order to produce its
> first line of output, in the cache-hot case? That is, is it just
> gitk's graph layout that is taking the time, or is it git rev-list
> (meaning that gitk needs to stop using --topo-order)?
Cold cache:
jonsmirl@jonsmirl:/opt/t1$ time git rev-list --all --topo-order
--parents >/dev/null
real 0m27.687s
user 0m5.672s
sys 0m0.560s
Hot cache:
jonsmirl@jonsmirl:/opt/t1$ time git rev-list --all --topo-order
--parents >/dev/null
real 0m6.041s
user 0m5.768s
sys 0m0.276s
jonsmirl@jonsmirl:/opt/t1$
I have enough RAM (3GB) that everything fits.
Hot cache, 27 seconds to get first line of display in gitk
It takes about two minutes get everything loaded into the window and
scroll to the head
This a 450MB pack, 250K commits, 2M objects.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Change set based shallow clone
From: Paul Mackerras @ 2006-09-09 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, linux@horizon.com, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609081600530.27779@g5.osdl.org>
Linus Torvalds writes:
> [ One way to do it might be: the normal ordering of revisions without
> "--topo-order) is "_close_ to topological", and gitk could just decide
> to re-compute the whole graph whenever it gets a commit that has a
> parent that it has already graphed. Done right, it would probably almost
> never actually generate re-computed graphs (if you only actually
> generate the graph when the user scrolls down to it).
>
> Getting rid of the --topo-order requirement would speed up gitk
> absolutely immensely, especially for unpacked cold-cache archives. So it
> would probably be a good thing to do, regardless of any shallow clone
> issues ]
>
> Hmm?
I recently added code to gitk to add extra commits after the graph has
been laid out, provided that the extra commits have one parent and no
children. If I generalized that to handle arbitrary numbers of
parents and children, it might go close to what you're suggesting.
It might get nasty if we have laid out A and then later B, and then C
comes along and turns out to be a child of A but a parent of B,
meaning that both B and C have to be put above A.
Another thing I have been thinking of is that gitk probably should
impose a time limit of say 3 months by default, unless the user
specifies some other ending condition (such as commitid.., ^commitid
or --since=something-else). Together with a menu to select the time
limit, I think that would be quite usable and would make gitk start up
*much* faster.
Paul.
^ permalink raw reply
* Re: Change set based shallow clone
From: Paul Mackerras @ 2006-09-08 23:45 UTC (permalink / raw)
To: Jon Smirl; +Cc: Linus Torvalds, linux@horizon.com, Git Mailing List
In-Reply-To: <9e4733910609081628w2a59551foc28c689d0538a984@mail.gmail.com>
Jon Smirl writes:
> gitk takes about a minute to come up on the Mozilla repo when
> everything is in cache. It takes about twice as long when things are
> cold. It's enough of delay that I don't use the tool.
How long does it take for git rev-list --topo-order to produce its
first line of output, in the cache-hot case? That is, is it just
gitk's graph layout that is taking the time, or is it git rev-list
(meaning that gitk needs to stop using --topo-order)?
Paul.
^ permalink raw reply
* Re: Change set based shallow clone
From: Jon Smirl @ 2006-09-08 23:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux@horizon.com, Git Mailing List, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0609081600530.27779@g5.osdl.org>
On 9/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Getting rid of the --topo-order requirement would speed up gitk
> absolutely immensely, especially for unpacked cold-cache archives. So it
> would probably be a good thing to do, regardless of any shallow clone
> issues ]
>
> Hmm?
gitk takes about a minute to come up on the Mozilla repo when
everything is in cache. It takes about twice as long when things are
cold. It's enough of delay that I don't use the tool.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox