* Re: [PATCH] git-svnimport: Parse log message for Signed-off-by: lines
From: Matthias Urlichs @ 2006-09-06 15:33 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Junio C Hamano, git
In-Reply-To: <20060906125317.GA21645@sashak.voltaire.com>
Hi,
Sasha Khapyorsky:
> At least I didn't succeed with reversed layout. With option
> -T <trunk>/$project import works but only for trunk branch, attempts
> to specify branch as -b <branches> or -b <branches>/$project don't help,
> the same is with tags.
>
That's true. The problem is that it wants the tag or branch name as the
last component of the path.
A more generic solution would be to use wildcards in the branch/tag
specification, to allow more than one wildcard, and to be able to
specify the exact form of the branch or tag name on the git side.
All of this should be specified in the repository's git config file,
not on the command line.
Somebody who wants to implement that is certainly invited to do so.
(I don't have time for that at the moment, unfortunately.)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: file rename causes history to disappear
From: Timo Hirvonen @ 2006-09-06 15:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <44FEE0BB.2060601@garzik.org>
Jeff Garzik <jeff@garzik.org> wrote:
> I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to
> drivers/ata.
>
> When I tried to look at the past history of a file using
> git-whatchanged, post-rename, it only shows the history from HEAD to the
> point of rename. Everything prior to the rename is lost.
>
> I also tried git-whatchanged on the old path, but that produces an error.
Try "git log -- old/path/...". Path limiting works without "--" only if
the path exists.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* file rename causes history to disappear
From: Jeff Garzik @ 2006-09-06 14:52 UTC (permalink / raw)
To: Git Mailing List
I moved a bunch of SATA drivers in the Linux kernel from drivers/scsi to
drivers/ata.
When I tried to look at the past history of a file using
git-whatchanged, post-rename, it only shows the history from HEAD to the
point of rename. Everything prior to the rename is lost.
I also tried git-whatchanged on the old path, but that produces an error.
[jgarzik@pretzel libata-dev]$ rpm -q git-core
git-core-1.4.1-1.fc5
Repository ("upstream" branch):
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Franck Bui-Huu @ 2006-09-06 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, git, rene.scharfe
In-Reply-To: <7vfyf6ce29.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:
>
>> git-archive is a command to make TAR and ZIP archives of a git tree.
>> It helps prevent a proliferation of git-{format}-tree commands.
>
> Thanks. I like the overall structure, at least mostly.
> Also dropping -tree suffix from the command name is nice, short
> and sweet.
>
great !
> Obviously I cannot apply this patch because it is totally
> whitespace damaged, but here are some comments.
(sigh), sorry for that.
>
>> diff --git a/archive.h b/archive.h
>> new file mode 100644
>> index 0000000..6c69953
>> --- /dev/null
>> +++ b/archive.h
>> @@ -0,0 +1,43 @@
>> +#ifndef ARCHIVE_H
>> +#define ARCHIVE_H
>> +
>> +typedef int (*write_archive_fn_t)(struct tree *tree,
>> + const unsigned char *commit_sha1,
>> + const char *prefix,
>> + time_t time,
>> + const char **pathspec);
>
> The type of the first argument might have to be different,
> depending on performance analysis by Rene on struct tree vs
> struct tree_desc.
>
OK. We'll wait for Rene.
>> +typedef int (*parse_extra_args_fn_t)(int argc,
>> + const char **argv,
>> + const char **reason);
>> +
>
> I do not see a way for parse_extra to record the parameter it
> successfully parsed, other than in a source-file-global, static
> variable. Not a very nice design for a library, if we are
> building one from scratch.
>
Interesting, could you explain why static variables are not nice ?
> Also, you are passing "reason" around from everywhere, but that
> is used by the caller to pass it to error(), so it might be
> simpler to just call error() when you want to assign to *reason,
> and make an error return. The caller does not have to do
> anything if you do that. Your way might interact with the
> remote protocol better, though -- I haven't thought this part
> through yet so do not take this as a serious objection, but just
> a comment.
>
You might have missed my second patch:
"[PATCH 2/2] Add git-upload-archive"
Basically the server can also use 'reason' to report a failure
description during NACK. I find it more useful than the simple
"server sent EOF" error message.
>> +struct archiver_struct {
>> + const char *name;
>> + write_archive_fn_t write_archive;
>> + parse_extra_args_fn_t parse_extra;
>> + const char *remote;
>> + const char *prefix;
>> +};
>
> Somehow "struct foo_struct" makes me feel uneasy, when I do not
> see the reason to call it "struct foo".
>
no strong feeling here. I'll call it "struct archiver". BTW there
are a couple of "struct foo_struct" in git source...
> Also, the first three fields are permanent property of the
> archiver while two are to wrap runtime arguments of one
> particular invocation. I would have liked...
>
'remote' case is not a generic argument that can be passed to
archiver backends. Remember, the archiver backends only do local
operation. They do not know about remote protocol which is part
of git-archive command. That's the reason why I think we shouldn't
make this field part of arguments structure. It completely change
the behaviour of git-archive when it is used.
>> +extern struct archiver_struct archivers[];
>
> ... this array to have only the former, and a separate structure
> "struct archive_args" to be defined.
>
> struct archive_args {
> const char *remote;
> const char *prefix;
> };
>
> After parse_archive_args finds the archiver specified with
> --format=*, it can call its parse_extra to retrieve a suitable
> struct that has struct archive_args embedded at the beginning,
> and then set remote and prefix on the returned structure.
>
One bad side is that we need to malloc this embedded structure.
Therefore we have to free this embedded structure somewhere.
We could have the following structures in archive.h, but we need
to export all these archiver backend definitions.
struct tar_archive_args {
int z_compress;
};
struct tar_archive_args {
[...]
};
struct archive_args {
const char *prefix;
struct tree *tree;
const unsigned char *commit_sha1;
const char *prefix;
time_t time;
const char **pathspec;
union {
struct tar_archive_args tar_args;
struct zip_archive_args zip_args;
} u;
};
struct archiver {
const char *name;
write_archive_fn_t write_archive;
parse_extra_args_fn_t parse_extra;
const char *remote;
};
typedef int (*write_archive_fn_t)(struct archive_args *archive_args);
> Then a specific parse_extra implementation can be written like this:
>
> static struct tar_archive_args {
> struct archive_args a;
> int z_compress;
> ...
> };
>
> struct archive_args *
> tar_archive_parse_extra(int ac, const char **av)
> {
> struct tar_archive_args *args = xcalloc(1, sizeof(*args));
>
> while (ac--) {
> const char *arg = *++av;
> if (arg[0] == '-' &&
> '0' <= arg[1] && arg[1] <= '9')
> args->z_compress = arg[1] - '0';
> ...
> }
> return (struct archive_args *)args;
> }
>
> and this can be passed to tar_archive_write_archive as an
> argument.
>
>> +extern int parse_treeish_arg(const char **argv,
>> + struct tree **tree,
>> + const unsigned char **commit_sha1,
>> + time_t *archive_time,
>> + const char *prefix,
>> + const char **reason);
>> +extern int write_tar_archive(struct tree *tree,
>> + const unsigned char *commit_sha1,
>> + const char *prefix,
>> + time_t time,
>> + const char **pathspec);
>
> I suspect we would want "struct tree_desc" based interface,
> instead of "struct tree".
>
>> +static const char archive_usage[] = \
>> +"git-archive --format=<fmt> [--prefix=<prefix>/] [-0|...|-9]
>> <tree-ish> [path...]";
>
> I do not think "-[0-9]" belongs to generic "git-archive". It
> does not make much sense to run compress on zip output. More
> like:
>
I forgot to remove that.
> git-archive --format=<fmt> [--prefix=<prefix>] [format specific options] <tree-ish> [path...]
>
I forgot to change that.
>
>> +static int run_remote_archiver(struct archiver_struct *ar, int argc,
>> + const char **argv)
>> +{
>> + char *url, buf[1024];
>> + pid_t pid;
>> + int fd[2];
>> + int len, rv;
>> +
>> + sprintf(buf, "git-upload-%s", ar->name);
>
> Are you calling git-upload-{tar,zip,rar,...} here?
>
yes. Actually git-upload-{tar,zip,...} commands are going to be
removed, but git-daemon know them as a daemon service. It will
map these services to the generic "git-upload-archive" command.
One benefit is that we could still disable TAR format and enable
TGZ one. Please take a look to the second patch that adds
git-upload-archive command.
>> + url = strdup(ar->remote);
>> + pid = git_connect(fd, url, buf);
>> + if (pid < 0)
>> + return pid;
>> +
>> + concat_argv(argc, argv, buf, sizeof(buf));
>> + packet_write(fd[1], "arguments %s\n", buf);
>> + packet_flush(fd[1]);
>
> Parameter concatenation with SP is a bad idea for two reasons.
> You cannot have SP in argument. Also packet_write() may not
> like the length of the arguments.
>
> A sequence of one argument per packet, with prefix "argument "
> for future extension so that we can send other stuff if/when
> needed, followed by a flush would be preferred.
Absolutely.
>
>> + /* Now, start reading from fd[0] and spit it out to stdout */
>> + rv = copy_fd(fd[0], 1);
>> + close(fd[0]);
>> + rv |= finish_connect(pid);
>
> It was painful to bolt progress indicator support onto original
> upload-pack protocol, while making sure that older and newer
> clients and servers interoperate with each other. Since this is
> a new protocol, we should start with the side-band support from
> the beginning (see upload-pack and look for use_sideband).
>
> Instead of sending the payload straight out, upload-archive side
> would read from the underlying archiver, and send it with
> one-byte prefix to say if it is a normal payload (band 1),
> message to stderr used to show progress indicator and error
> messages (band 2), or error exit situation (band 3). The client
> side here would receive the packetized data and do the reverse.
>
OK, I'll take a look
>> +int parse_treeish_arg(const char **argv, struct tree **tree,
>> + const unsigned char **commit_sha1,
>> + time_t *archive_time, const char *prefix,
>> + const char **reason)
>> +{
>> ...
>> + if (prefix) {
>> + unsigned char tree_sha1[20];
>> + unsigned int mode;
>> + int err;
>> +
>> + err = get_tree_entry((*tree)->object.sha1, prefix,
>> + tree_sha1, &mode);
>> + if (err || !S_ISDIR(mode)) {
>> + *reason = "current working directory is untracked";
>> + goto out;
>> + }
>> + free(*tree);
>> + *tree = parse_tree_indirect(tree_sha1);
>> + }
>
> I like the simplicity of just optionally sending one subtree (or
> the whole thing), but I think this part would be made more
> efficient if we go with "struct tree_desc" based interface.
>
> Also I wonder how this interacts with the pathspec you take from
> the command line. Personally I think this single subtree
> support is good enough and limiting with pathspec is not needed.
>
As I said in a previous email, I'm new with git internals. I prefer
let that part to others who better have a better knowledge on the
subject. I'll dig into that later though...
>> +int parse_archive_args(int argc, const char **argv,
>> + struct archiver_struct **ar,
>> + const char **reason)
>> +{
>> ...
>> + if (arg[0] == '-' && isdigit(arg[1]) && arg[2] == '\0') {
>> + zlib_compression_level = arg[1] - '0';
>> + continue;
>> + }
>
> Commented on this part already.
>
OK
>> + if (list) {
>> + if (!remote) {
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(archivers); i++)
>> + printf("%s\n", archivers[i].name);
>> + exit(0);
>> + }
>
> You do not need a different "i" that shadows the outer one here.
Yes.
>
>> + (*ar)->remote = remote;
>> + (*ar)->prefix = prefix ? : "";
>
> Please be nicer to other people by staying away from GNU
> extension "A ? : B", especially when A is so simple.
>
sure.
Thanks for your comments,
Franck
^ permalink raw reply
* Re: git.kernel.org not putting out or git-daemon bug?
From: Andreas Ericsson @ 2006-09-06 13:15 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <44FEC6BE.5060301@op5.se>
Andreas Ericsson wrote:
> Is it just me, or is anyone else having problems 'git fetch'-ing from
> git.kernel.org? I've been trying on and off for two hours now, but keep
> getting
>
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
>
> Around 10 o'clock GMT I got a couple of timeouts, but I haven't seen one
> of those for several hours now.
>
> Using git version 1.4.2.ga444 to do the fetching, and trying to pull
> things on to a clone of that revision of the git repo.
>
Fetch over rsync seems to work fine, but git version 1.4.2.g8f5d has no
better luck fetching over the git-protocol.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git.kernel.org not putting out or git-daemon bug?
From: Andy Whitcroft @ 2006-09-06 13:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44FEC6BE.5060301@op5.se>
Andreas Ericsson wrote:
> Is it just me, or is anyone else having problems 'git fetch'-ing from
> git.kernel.org? I've been trying on and off for two hours now, but keep
> getting
>
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
>
> Around 10 o'clock GMT I got a couple of timeouts, but I haven't seen one
> of those for several hours now.
>
> Using git version 1.4.2.ga444 to do the fetching, and trying to pull
> things on to a clone of that revision of the git repo.
I am seeing the same. I switched my URL: to http and that got me the
data, so its still out there.
-apw
^ permalink raw reply
* [PATCH 3/7] gitweb: Use @hist_opts as git-rev-list parameters in git_history
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11575480912922-git-send-email-jnareb@gmail.com>
Add new global configuration variable @hist_opts, which holds
additional, history specific options (parameters) to git-rev-list
called in git_history subroutine. Default value is '--full-history',
as it was.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4c76032..2191853 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -176,9 +176,23 @@ # - more costly is '-C' (or '-C', '-M'),
# (number of changed files + number of removed files) * (number of new files)
# - even more costly is '-C', '--find-copies-harder' with cost
# (number of files in the original tree) * (number of new files)
-# - one might want to include '-B' option, e.g. '-B', '-M'
+# - one might want to include '-B' option, e.g. have it ('-B', '-M'),
+# or for example '-l<num>' together with '-M' and perhaps '-C'
our @diff_opts = ('-M'); # taken from git_commit
+# options fo git-rev-list used in git_history
+# - default is '--full-history', which is slowest but works with merges,
+# and was done to not change the output from previous version when
+# path limiting was done by piping revisions to git-diff-tree --stdin
+# - less costly is (), i.e. without '--full-history', which of course
+# changes output and provides _simplified_ history of a file
+# - for files which appeared late in the history less costly is
+# --full-history, --remove-empty, although it changes output in
+# the rare case when name vanished the appeared thorough the history;
+# it improves performance of course only the last page of history
+# - least costly, but changing output, is having --remove-mepty only
+our @hist_opts = ('--full-history');
+
our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "++GITWEB_CONFIG++";
do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
@@ -3137,7 +3151,7 @@ sub git_history {
}
open my $fd, "-|",
- git_cmd(), "rev-list", $limit, "--full-history", $hash_base, "--", $file_name
+ git_cmd(), "rev-list", $limit, @hist_opts, $hash_base, "--", $file_name
or die_error(undef, "Open git-rev-list-failed");
my @revlist = map { chomp; $_ } <$fd>;
close $fd
--
1.4.2
^ permalink raw reply related
* [PATCH 5/7] gitweb: Use parse_rev_list in git_shortlog and git_history
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11575480922634-git-send-email-jnareb@gmail.com>
Use parse_rev_list in git_shortlog and git_history, and modify
git_shortlog_body and git_history_body to accept parse_rev_list
output; in the future we can remove support for older unparsed
revision list from git_shortlog_body and git_history_body.
Other places when we can use parse_rev_list are git_log and git_rss.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8aeca52..e665d94 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1946,7 +1946,7 @@ sub git_shortlog_body {
my $commit = $revlist->[$i];
#my $ref = defined $refs ? format_ref_marker($refs, $commit) : '';
my $ref = format_ref_marker($refs, $commit);
- my %co = parse_commit($commit);
+ my %co = ref $commit ? %$commit : parse_commit($commit);
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
@@ -1987,12 +1987,13 @@ sub git_history_body {
print "<table class=\"history\" cellspacing=\"0\">\n";
my $alternate = 0;
for (my $i = $from; $i <= $to; $i++) {
- if ($revlist->[$i] !~ m/^([0-9a-fA-F]{40})/) {
+ if (ref($revlist->[$i]) ne "HASH" &&
+ $revlist->[$i] !~ m/^([0-9a-fA-F]{40})/) {
next;
}
my $commit = $1;
- my %co = parse_commit($commit);
+ my %co = ref $commit ? %$commit : parse_commit($commit);
if (!%co) {
next;
}
@@ -3179,12 +3180,9 @@ sub git_history {
$ftype = git_get_type($hash);
}
- open my $fd, "-|",
- git_cmd(), "rev-list", $limit, @hist_opts, $hash_base, "--", $file_name
- 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");
+ my @revlist = parse_rev_list($limit, @hist_opts, $hash_base, "--", $file_name)
+ or die_error(undef, "Parsing git-rev-list failed");
+
my $paging_nav = '';
if ($page > 0) {
@@ -3387,10 +3385,9 @@ 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
- or die_error(undef, "Open git-rev-list failed");
- my @revlist = map { chomp; $_ } <$fd>;
- close $fd;
+ my @revlist = parse_rev_list($limit, $hash)
+ or die_error(undef, "Parsing git-rev-list failed");
+
my $paging_nav = format_paging_nav('shortlog', $hash, $head, $page, $#revlist);
my $next_link = '';
--
1.4.2
^ permalink raw reply related
* [PATCH 7/7] gitweb: Set page to 0 if it is not defined, in git_history
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11575480922345-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index be4db08..edded74 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3153,6 +3153,9 @@ sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
}
+ if (!defined $page) {
+ $page = 0;
+ }
my $ftype;
my %co = parse_commit($hash_base);
if (!%co) {
--
1.4.2
^ permalink raw reply related
* [PATCH 4/7] gitweb: Add parse_rev_list for later use
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11575480922090-git-send-email-jnareb@gmail.com>
Add parse_rev_list to generate _parsed_ list of revisions, combining
getting the list of revisions, and parsing of individual revisions
into one subroutine. It is to avoid code like below
open my $fd, "-|", git_cmd(), "rev-list", $limit, $hash
or die_error(undef, "Open git-rev-list failed");
my @revlist = map { chomp; $_ } <$fd>;
...
foreach my $commit (@revlist) {
my %co = parse_commit($commit);
where parse_commit subroutine calls git-rev-list with '--max-count=1'
to parse individual commit. Using parse_rev_list will avoid
unnecessary forks.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2191853..8aeca52 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1125,6 +1125,35 @@ sub git_get_refs_list {
return \@reflist;
}
+# To use only one invocation of git-rev-list, instead of getting
+# the list of revisions and then using git-rev-list per revision
+# to parse individual commits.
+#
+# parse_rev_list parameters are passed to git-rev-list, so they should
+# include at least starting revision; just in case we default to HEAD
+sub parse_rev_list {
+ my @rev_opts = @_;
+ my @revlist;
+
+ @rev_opts = ("HEAD") unless @rev_opts;
+
+ local $/ = "\0";
+ open my $fd, "-|", git_cmd(), "rev-list", "--header", "--parents", @rev_opts
+ or return \@revlist;
+
+ while (my $revinfo = <$fd>) {
+ chomp $revinfo;
+ my @commit_lines = split '\n', $revinfo;
+ my %co = parse_commit(undef, \@commit_lines);
+
+ push @revlist, \%co;
+ }
+
+ close $fd;
+
+ return wantarray ? @revlist : \@revlist;
+}
+
## ----------------------------------------------------------------------
## filesystem-related functions
--
1.4.2
^ permalink raw reply related
* [PATCH 6/7] gitweb: Assume parsed revision list in git_shortlog_body and git_history_body
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11575480921279-git-send-email-jnareb@gmail.com>
Assume that git_shortlog and git_history uses parse_rev_list
subroutine, and git_shortlog_body and git_history_body gets parsed
revision list as a parameter.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 35 ++++++++++++-----------------------
1 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e665d94..be4db08 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1943,21 +1943,19 @@ sub git_shortlog_body {
print "<table class=\"shortlog\" cellspacing=\"0\">\n";
my $alternate = 0;
for (my $i = $from; $i <= $to; $i++) {
- my $commit = $revlist->[$i];
- #my $ref = defined $refs ? format_ref_marker($refs, $commit) : '';
+ my $co = $revlist->[$i];
+ my $commit = $co->{'id'};
my $ref = format_ref_marker($refs, $commit);
- my %co = ref $commit ? %$commit : parse_commit($commit);
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- # git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
- print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ print "<td title=\"$co->{'age_string_age'}\"><i>$co->{'age_string_date'}</i></td>\n" .
+ "<td><i>" . esc_html(chop_str($co->{'author_name'}, 10)) . "</i></td>\n" .
"<td>";
- print format_subject_html($co{'title'}, $co{'title_short'},
+ print format_subject_html($co->{'title'}, $co->{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
@@ -1987,17 +1985,8 @@ sub git_history_body {
print "<table class=\"history\" cellspacing=\"0\">\n";
my $alternate = 0;
for (my $i = $from; $i <= $to; $i++) {
- if (ref($revlist->[$i]) ne "HASH" &&
- $revlist->[$i] !~ m/^([0-9a-fA-F]{40})/) {
- next;
- }
-
- my $commit = $1;
- my %co = ref $commit ? %$commit : parse_commit($commit);
- if (!%co) {
- next;
- }
-
+ my $co = $revlist->[$i];
+ my $commit = $co->{'id'};
my $ref = format_ref_marker($refs, $commit);
if ($alternate) {
@@ -2006,12 +1995,12 @@ sub git_history_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
- print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- # shortlog uses chop_str($co{'author_name'}, 10)
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ print "<td title=\"$co->{'age_string_age'}\"><i>$co->{'age_string_date'}</i></td>\n" .
+ # shortlog uses chop_str($co->{'author_name'}, 10)
+ "<td><i>" . esc_html(chop_str($co->{'author_name'}, 15, 3)) . "</i></td>\n" .
"<td>";
- # originally git_history used chop_str($co{'title'}, 50)
- print format_subject_html($co{'title'}, $co{'title_short'},
+ # originally git_history used chop_str($co->{'title'}, 50)
+ print format_subject_html($co->{'title'}, $co->{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
--
1.4.2
^ permalink raw reply related
* [PATCH 1/7] gitweb: Make pickaxe search a feature
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <200609061504.40725.jnareb@gmail.com>
As pickaxe search (selected using undocumented 'pickaxe:' operator in
search query) is resource consuming, allow to turn it on/off using
feature meachanism.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d6f546d..e95d16f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -93,6 +93,11 @@ our %feature = (
'override' => 0,
# => [content-encoding, suffix, program]
'default' => ['x-gzip', 'gz', 'gzip']},
+
+ 'pickaxe' => {
+ 'sub' => \&feature_pickaxe,
+ 'override' => 0,
+ 'default' => [0]},
);
sub gitweb_check_feature {
@@ -146,6 +151,24 @@ sub feature_snapshot {
return ($ctype, $suffix, $command);
}
+# To enable system wide have in $GITWEB_CONFIG
+# $feature{'pickaxe'}{'default'} = [1];
+# To have project specific config enable override in $GITWEB_CONFIG
+# $feature{'pickaxe'}{'override'} = 1;
+# and in project config gitweb.pickaxe = 0|1;
+
+sub feature_pickaxe {
+ my ($val) = git_get_project_config('pickaxe', '--bool');
+
+ if ($val eq 'true') {
+ return (1);
+ } elsif ($val eq 'false') {
+ return (0);
+ }
+
+ return ($_[0]);
+}
+
# rename detection options for git-diff and git-diff-tree
# - default is '-M', with the cost proportional to
# (number of removed files) * (number of new files).
@@ -3131,8 +3154,7 @@ sub git_search {
if (!%co) {
die_error(undef, "Unknown commit object");
}
- # 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;
@@ -3144,6 +3166,13 @@ sub git_search {
} elsif ($searchtext =~ s/^pickaxe\\://i) {
$commit_search = 0;
$pickaxe_search = 1;
+
+ # 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 ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ if (!$have_pickaxe) {
+ die_error('403 Permission denied', "Permission denied");
+ }
}
git_header_html();
git_print_page_nav('','', $hash,$co{'tree'},$hash);
--
1.4.2
^ permalink raw reply related
* [PATCH 2/7] gitweb: Paginate history output
From: Jakub Narebski @ 2006-09-06 13:08 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1157548091229-git-send-email-jnareb@gmail.com>
git_history output is now divided into pages, like git_shortlog,
git_tags and git_heads output. As whole git-rev-list output is now
read into array before writing anything, it allows for better
signaling of errors.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 61 +++++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e95d16f..4c76032 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1936,12 +1936,15 @@ sub git_shortlog_body {
sub git_history_body {
# Warning: assumes constant type (blob or tree) during history
- my ($fd, $refs, $hash_base, $ftype, $extra) = @_;
+ my ($revlist, $from, $to, $refs, $hash_base, $ftype, $extra) = @_;
+
+ $from = 0 unless defined $from;
+ $to = $#{$revlist} unless (defined $to && $to <= $#{$revlist});
print "<table class=\"history\" cellspacing=\"0\">\n";
my $alternate = 0;
- while (my $line = <$fd>) {
- if ($line !~ m/^([0-9a-fA-F]{40})/) {
+ for (my $i = $from; $i <= $to; $i++) {
+ if ($revlist->[$i] !~ m/^([0-9a-fA-F]{40})/) {
next;
}
@@ -3122,24 +3125,62 @@ sub git_history {
if (!%co) {
die_error(undef, "Unknown commit object");
}
+
my $refs = git_get_references();
- git_header_html();
- git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ my $limit = sprintf("--max-count=%i", (100 * ($page+1)));
+
if (!defined $hash && defined $file_name) {
$hash = git_get_hash_by_path($hash_base, $file_name);
}
if (defined $hash) {
$ftype = git_get_type($hash);
}
- git_print_page_path($file_name, $ftype, $hash_base);
open my $fd, "-|",
- git_cmd(), "rev-list", "--full-history", $hash_base, "--", $file_name;
+ git_cmd(), "rev-list", $limit, "--full-history", $hash_base, "--", $file_name
+ 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");
- git_history_body($fd, $refs, $hash_base, $ftype);
+ my $paging_nav = '';
+ if ($page > 0) {
+ $paging_nav .=
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name)},
+ "first");
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name, page=>$page-1),
+ -accesskey => "p", -title => "Alt-p"}, "prev");
+ } else {
+ $paging_nav .= "first";
+ $paging_nav .= " ⋅ prev";
+ }
+ if ($#revlist >= (100 * ($page+1)-1)) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name, page=>$page+1),
+ -accesskey => "n", -title => "Alt-n"}, "next");
+ } else {
+ $paging_nav .= " ⋅ next";
+ }
+ my $next_link = '';
+ if ($#revlist >= (100 * ($page+1)-1)) {
+ $next_link =
+ $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
+ file_name=>$file_name, page=>$page+1),
+ -title => "Alt-n"}, "next");
+ }
+
+ git_header_html();
+ git_print_page_nav('history','', $hash_base,$co{'tree'},$hash_base, $paging_nav);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_page_path($file_name, $ftype, $hash_base);
+
+ git_history_body(\@revlist, ($page * 100), $#revlist,
+ $refs, $hash_base, $ftype, $next_link);
- close $fd;
git_footer_html();
}
--
1.4.2
^ permalink raw reply related
* [PATCH 0/7] gitweb: Trying to improve history view speed
From: Jakub Narebski @ 2006-09-06 13:04 UTC (permalink / raw)
To: git
This series of patches tries to improve gitweb speed somewhat.
Patch 1/7 makes possible to easily enable/disable pickaxe search
('pickaxe:' operator), by making pickaxe search a feature.
Patch 2/7 paginates history output, which makes "history" view
for files with longer history appear much faster. Patch 7/7 fixes
omission in pagination of history output. This patch is updated
to newer mod_perl compatibile gitweb version, and corrected version
of previous patch with the same title.
Patch 3/7 makes it easy to make history output faster, if changing
the output (making output backward-incompatibile), by making it easy
to remove '--full-history' option and/or add '--remove-empty' option.
Patches 4/7, 5/7, 6/7 tries to make gitweb faster by eliminating
calls to git-rev-list, combining generating list of revision and
commit parsing into one subroutine, using one call to git-rev-list.
Unfortunately, git-rev-list is broken: 'git rev-list <commit>
--full-history --parents -- <filename>' shows all merges in addition
to what 'git rev-list <commit> --parents -- <filename>' and
'git rev-list <commit> --full-history -- <filename>' shows, see
"git-rev-list --full-history --parents doesn't respect path limit
and shows all merges" thread
Message-ID: <edmabt$3tc$1@sea.gmane.org>
http://permalink.gmane.org/gmane.comp.version-control.git/26514
So probably those patches should be dropped or put in freezer until
git-rev-list is corrected.
Benchmark:
First column is the patch number (0 means state before first patch),
columns 2 to 4 are results of running gitweb from command line,
using /usr/bin/time -f "%e %U %s", columns 5 to 8 are taken from
ApacheBench 2.0.41-dev, run with -n 10 option, 5 and 6 for mod_cgi,
7 and 8 for mod_perl (probably not configured correctly, as it is
slower than CGI version).
# 1:gitweb/new~n 2:%e 3:%U 4:%s 5:ab-n10_cgi_time[ms] 6:[+/-sd] 7:ab-n10_perl_time[ms] 8:[+/-sd]
0 11.38 9.66 0 11350.681 96.8 11950.143 546.3
1 11.37 9.71 0 18150.842 4327.8 14535.352 3149.1
2 3.61 2.16 0 3719.344 261.9 3975.663 219.6
3 3.62 2.20 0 3576.822 41.2 3929.396 201.6
4 3.61 2.13 0 3620.246 188.3 3943.111 184.1
4 3.61 2.13 0 3622.156 172.6 3716.499 53.0
#5 0/0 0/0 0/0 0/0 0/0 0/0 0/0
6 2.60 1.56 0 2809.344 369.5 2823.286 245.9
7 2.59 1.53 0 2621.073 234.2 2742.230 96.6
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
Diffstat:
---
gitweb/gitweb.perl | 180 +++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 141 insertions(+), 39 deletions(-)-
P.S. Is putting diffstat in such a series of patches actually usefull?
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* git.kernel.org not putting out or git-daemon bug?
From: Andreas Ericsson @ 2006-09-06 13:01 UTC (permalink / raw)
To: Git Mailing List
Is it just me, or is anyone else having problems 'git fetch'-ing from
git.kernel.org? I've been trying on and off for two hours now, but keep
getting
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
Around 10 o'clock GMT I got a couple of timeouts, but I haven't seen one
of those for several hours now.
Using git version 1.4.2.ga444 to do the fetching, and trying to pull
things on to a clone of that revision of the git repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-svnimport: Parse log message for Signed-off-by: lines
From: Sasha Khapyorsky @ 2006-09-06 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7v8xkxc2tr.fsf@assigned-by-dhcp.cox.net>
On 16:26 Tue 05 Sep , Junio C Hamano wrote:
> Sasha Khapyorsky <sashak@voltaire.com> writes:
>
> > BTW, what about to importing subdirectories, like this:
> >
> > <trunk>/path/to/subdir
> > <branches>/path/to/subdir
> >
> > Is this could be improvement?
>
> I somehow had an impression that svnimport dealt with the
> reversed layout already, although $project/{trunk,branches,tags}
> layout is assumed by default; maybe I was mistaken.
At least I didn't succeed with reversed layout. With option
-T <trunk>/$project import works but only for trunk branch, attempts
to specify branch as -b <branches> or -b <branches>/$project don't help,
the same is with tags.
> If the tool can automatically detect the layout the remote
> project employs, and adjust the default accordingly, I would
> imagine that would be a useful addition.
Not really automatically, but $project may be passed as option argument
in command line (let's say -p or -P), then git-svnimport will attempt to
parse such SVN repo layout:
<trunk>/$project
<branches>/<names>/$project
...
I will verify the patch (it worked only once with our specific project -
OpenSM) and then will post.
Sasha
^ permalink raw reply
* [PATCH] send pack switch to using git rev list stdin v2
From: Andy Whitcroft @ 2006-09-06 12:40 UTC (permalink / raw)
To: git
In-Reply-To: <44FEBFD6.10709@shadowen.org>
send-pack: switch to using git-rev-list --stdin v2
When we are generating packs to update remote repositories we
want to supply as much information as possible about the revisions
that already exist to rev-list in order optimise the pack as much
as possible. We need to pass two revisions for each branch we are
updating in the remote repository and one for each additional branch.
Where the remote repository has numerous branches we can run out
of command line space to pass them.
Utilise the git-rev-list --stdin mode to allow unlimited numbers
of revision constraints. This allows us to move back to the much
simpler unordered revision selection code.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/send-pack.c b/send-pack.c
index ac4501d..b403ee9 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -38,9 +38,8 @@ static void exec_pack_objects(void)
static void exec_rev_list(struct ref *refs)
{
- struct ref *ref;
- static const char *args[1000];
- int i = 0, j;
+ static const char *args[4];
+ int i = 0;
args[i++] = "rev-list"; /* 0 */
if (use_thin_pack) /* 1 */
@@ -48,43 +47,29 @@ static void exec_rev_list(struct ref *re
else
args[i++] = "--objects";
- /* First send the ones we care about most */
- for (ref = refs; ref; ref = ref->next) {
- if (900 < i)
- die("git-rev-list environment overflow");
- if (!is_zero_sha1(ref->new_sha1)) {
- char *buf = xmalloc(100);
- args[i++] = buf;
- snprintf(buf, 50, "%s", sha1_to_hex(ref->new_sha1));
- buf += 50;
- if (!is_zero_sha1(ref->old_sha1) &&
- has_sha1_file(ref->old_sha1)) {
- args[i++] = buf;
- snprintf(buf, 50, "^%s",
- sha1_to_hex(ref->old_sha1));
- }
- }
- }
+ args[i++] = "--stdin";
- /* Then a handful of the remainder
- * NEEDSWORK: we would be better off if used the newer ones first.
- */
- for (ref = refs, j = i + 16;
- i < 900 && i < j && ref;
- ref = ref->next) {
- if (is_zero_sha1(ref->new_sha1) &&
- !is_zero_sha1(ref->old_sha1) &&
- has_sha1_file(ref->old_sha1)) {
- char *buf = xmalloc(42);
- args[i++] = buf;
- snprintf(buf, 42, "^%s", sha1_to_hex(ref->old_sha1));
- }
- }
args[i] = NULL;
execv_git_cmd(args);
die("git-rev-list exec failed (%s)", strerror(errno));
}
+static void builtin_rev_list_generate(struct ref *refs)
+{
+ while (refs) {
+ if (!is_zero_sha1(refs->old_sha1) &&
+ has_sha1_file(refs->old_sha1)) {
+ printf("^%s\n", sha1_to_hex(refs->old_sha1));
+ }
+ if (!is_zero_sha1(refs->new_sha1)) {
+ printf("%s\n", sha1_to_hex(refs->new_sha1));
+ }
+ refs = refs->next;
+ }
+
+ exit(0);
+}
+
static void rev_list(int fd, struct ref *refs)
{
int pipe_fd[2];
@@ -111,13 +96,38 @@ static void rev_list(int fd, struct ref
exec_rev_list(refs);
}
+static void rev_list_generate(int fd, struct ref *refs)
+{
+ int pipe_fd[2];
+ pid_t rev_list_generate_pid;
+
+ if (pipe(pipe_fd) < 0)
+ die("rev-list-generate setup: pipe failed");
+ rev_list_generate_pid = fork();
+ if (!rev_list_generate_pid) {
+ dup2(pipe_fd[0], 0);
+ dup2(fd, 1);
+ close(pipe_fd[0]);
+ close(pipe_fd[1]);
+ close(fd);
+ rev_list(fd, refs);
+ die("rev-list setup failed");
+ }
+ if (rev_list_generate_pid < 0)
+ die("rev-list-generate fork failed");
+ dup2(pipe_fd[1], 1);
+ close(pipe_fd[0]);
+ close(pipe_fd[1]);
+ close(fd);
+ builtin_rev_list_generate(refs);
+}
static void pack_objects(int fd, struct ref *refs)
{
pid_t rev_list_pid;
rev_list_pid = fork();
if (!rev_list_pid) {
- rev_list(fd, refs);
+ rev_list_generate(fd, refs);
die("rev-list setup failed");
}
if (rev_list_pid < 0)
^ permalink raw reply related
* Re: [PATCH 2/2] Teach rev-list an option to read revs from the standard input.
From: Andy Whitcroft @ 2006-09-06 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64g1a9f7.fsf@assigned-by-dhcp.cox.net>
Ok, I've tested this with an updated version of my patch to make
send-pack use this (which I'll send out following this message) and it
seems to work pretty well.
-apw
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Jakub Narebski @ 2006-09-06 11:46 UTC (permalink / raw)
To: git
In-Reply-To: <20060906113052.GC23891@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Sep 06, 2006 at 12:22:47PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>>
>> Somehow, the GitWiki (which is MoinMoin wiki) lost the ability to parse
>> macros. Macros are now output as is, instead of being substitutes with
>> their expansion. It looks like MediaWiki-like syntax plugin got broken,
>> because besides of {{macroname}} not being expanded, additionally pipe
>> links [[target|label]] are not parsed.
>>
>> See for example
>> http://git.or.cz/gitwiki/RecentChanges
>> http://git.or.cz/gitwiki/FindPage
>> http://git.or.cz/gitwiki/SystemInfo
>>
>> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>> (table of contents lost)
>>
>> So anyone has idea what has happened, and how to repair it?
>
> this was connected with the server upgrade, sorry. Fixed.
Hmm... I still get for http://git.or.cz/gitwiki/RecentChanges
{{RandomQuote()}}
{{RecentChanges}}
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Petr Baudis @ 2006-09-06 11:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edm7h3$nij$1@sea.gmane.org>
Hi,
Dear diary, on Wed, Sep 06, 2006 at 12:22:47PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Somehow, the GitWiki (which is MoinMoin wiki) lost the ability to parse
> macros. Macros are now output as is, instead of being substitutes with
> their expansion. It looks like MediaWiki-like syntax plugin got broken,
> because besides of {{macroname}} not being expanded, additionally pipe
> links [[target|label]] are not parsed.
>
> See for example
> http://git.or.cz/gitwiki/RecentChanges
> http://git.or.cz/gitwiki/FindPage
> http://git.or.cz/gitwiki/SystemInfo
>
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> (table of contents lost)
>
> So anyone has idea what has happened, and how to repair it?
this was connected with the server upgrade, sorry. Fixed.
There are unfortunately some stability problems with the new server,
we hope to get that sorted out; in case of downtime we'll be falling
back to the original server which is still running, but I disabled the
wiki there in order not to lose changes when flipping back and forth.
--
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
* git-rev-list --full-history --parents doesn't respect path limit and shows all merges
From: Jakub Narebski @ 2006-09-06 11:11 UTC (permalink / raw)
To: git
When trying to speed-up gitweb by using only one git-rev-list invocation to
get _parsed_ list of revisions, and not first call git-rev-list to get list
of revisions, and then for each revision call git-rev-list --max-count=1
--parennts --header to parse a commit, I have encountered the following
error in (most probably) --full-history implementation.
Namely the following work as expected, returning only one commit:
git rev-list HEAD -- gitweb/git-logo.png
git rev-list HEAD --full-history -- gitweb/git-logo.png
git rev-list HEAD --parents -- gitweb/git-logo.png
but the following command
git rev-list HEAD --full-history --parents -- gitweb/git-logo.png
returns additionally _all_ the merges.
I don't know if it is a feature or a bug (I think that is the latter),
but it seriously screw mentioned plan to make gitweb faster a bit.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* GitWiki lost ability to parse macros
From: Jakub Narebski @ 2006-09-06 10:22 UTC (permalink / raw)
To: git
Somehow, the GitWiki (which is MoinMoin wiki) lost the ability to parse
macros. Macros are now output as is, instead of being substitutes with
their expansion. It looks like MediaWiki-like syntax plugin got broken,
because besides of {{macroname}} not being expanded, additionally pipe
links [[target|label]] are not parsed.
See for example
http://git.or.cz/gitwiki/RecentChanges
http://git.or.cz/gitwiki/FindPage
http://git.or.cz/gitwiki/SystemInfo
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
(table of contents lost)
So anyone has idea what has happened, and how to repair it?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Why is there a --binary option needed for git-apply?
From: Shawn Pearce @ 2006-09-06 3:38 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <874pvmxikq.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> Shawn Pearce was kind enough to direct me to the --binary option for
> git-apply which solved my problem. But that left me wondering why
> git-apply requires this extra command-line option to do its
> job. Shouldn't git-apply simply apply the patch it is given?
>
> If there is some reason for git-apply to only apply binary patches
> when under the duress of --binary, then at the very least it could use
> a better error message explaining the situation.
I see no reason why git-apply shouldn't always have --binary enabled.
If the patch contains full pre-image/post-image blob IDs and we have
an exact match against the pre-image and we have the post-image
in our tree it should just apply even if the user didn't supply
--binary. If the patch contains a binary delta and we have an
exact match against the pre-image it should also just apply.
But if there's a binary hunk and we lack the full pre/post image blob
IDs, we lack the post image and there's no detla, or the pre-image
doesn't exactly match then we should obviously still abort with a
reasonable error message as there's no sane course of action to take.
--
Shawn.
^ permalink raw reply
* pack-objects and rev-list status updates
From: Junio C Hamano @ 2006-09-06 9:38 UTC (permalink / raw)
To: git
Tonight's "master" has an update to teach git-rev-list to read
list of rev arguments from its standard input. We owe Andy
Whitcroft a big credit for starting this topic.
This required splitting out part of setup_revision() and make it
callable from the side. Thanks to this split, it got a lot easier
to teach pack-objects to do a similar trick. I did a few:
- Earlier patch I sent to give command line parameters similar
to rev-list to pack-objects was reworked on. I chose to feed
rev arguments from its standard input; so
echo master..next | pack-objects --revs --stdout
would do what you would expect.
- A patch before that one to add --unpacked=<existing pack>
option was resurrected and further reworked on. Now you can
say,
rev-list --objects --unpacked=$active --all |
pack-objects $new
and/or
pack-objects --unpacked=$active --all $new </dev/null
The </dev/null at the end is ugly but the command always
reads from its standard input. Unlike the "something like
this?" patch, this version can take more than one such
"pretend things in these packs are unpacked" arguments.
- I also told pack-objects to understand --thin, so you can do
a thin pack this:
echo master..next | pack-objects --thin --stdout
The equivalent expressed in the old way is:
rev-list --objects-edge master..next |
pack-objects --stdout
Note that --thin is only usable with --stdout, as before.
Andy has a patch to use "rev-list --stdin" to lift the exec
arguments limit from send-pack; I tweaked it slightly and tested
it minimally. I think the logical next step would be to use
"pack-objects --stdin" there and lose another pipe and a process.
We also should be able to do the same for upload-pack. Now the
groundwork is more or less done, I think this is a good exercise
for a wannabe git hacker. Hint hint...
I do not expect to be working on git tomorrow (Wednesday my
time), so I will not be merging any of the above (except the
"rev-list --stdin" change) in "next" tonight (eh, it is already
Wednesday wee morning), but they will appear in "pu".
^ permalink raw reply
* Re: [PATCH 2/2] Teach rev-list an option to read revs from the standard input.
From: Jakub Narebski @ 2006-09-06 9:12 UTC (permalink / raw)
To: git
In-Reply-To: <7v64g1a9f7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Note that you still have to give all the flags from the command
> line; only rev arguments (including A..B, A...B, and A^@ notations)
> can be give from the standard input.
Does this include ^A notation?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox