* Re: [PATCH 2] gitweb: Use list for of open for running git commands, thorougly.
From: Jakub Narebski @ 2006-07-31 11:42 UTC (permalink / raw)
To: git
In-Reply-To: <7virle6o5z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This, together with PATCH 6, seems to break "history" link.
> Visit a repository (summary page), click on "tree" on the second
> line, and click on "history" (on any blob or tree).
Strange... returning this part of git_history to previous version, i.e.
open my $fd, "-|",
"$GIT rev-list --full-history $hash_base -- \'$file_name\'";
still gives no history. Curious. Will examine that...
> BTW, please be careful on trailing whitespaces.
I'm sorry for that. I have forgot to turn-on default git pre-commit it clone
of git repository I'm not working on...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git merge (resolve) _is_ stupid
From: Johannes Schindelin @ 2006-07-31 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j1u6nsx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 31 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The culprit is the call to parse_commit() in merge_bases(). How about
> > this?
>
> Do you mean merge_bases() in commit.c which is called by
> get_merge_bases()?
Yes, the same.
> If so the patch feels like papering over a more grave bug -- the result
> from make_virtual_commit does not seem to have any proper parent
> information, so how is merge_bases() expected to return anything
> sensible?
It is not a grave bug, but very much by design: remember, a recursive
merge means that if you have more than one merge base, then the merge
bases are merged first. And the result is -- tada -- a virtual commit.
It does have (virtual) parents, but we do _not_ want to traverse them in
merge_bases().
However, they have (virtual) children, and _these_ relationships are
important: in your case (I guess) that the merge_bases() finds the
virtual commit, since (with the virtual history) the other commit
is just a fast-forward.
So, a virtual commit is something like a merge base combining two or more
merge bases.
> I am confused, but going to bed first.
I know the feeling ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git merge (resolve) _is_ stupid
From: Junio C Hamano @ 2006-07-31 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607311236070.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The culprit is the call to parse_commit() in merge_bases(). How about
> this?
Do you mean merge_bases() in commit.c which is called by
get_merge_bases()? If so the patch feels like papering over a
more grave bug -- the result from make_virtual_commit does not
seem to have any proper parent information, so how is merge_bases()
expected to return anything sensible?
I am confused, but going to bed first.
^ permalink raw reply
* Re: [RFC] Add the --color-words option to the diff options family
From: Johannes Schindelin @ 2006-07-31 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqr66o4e.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 31 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > With this option, the changed words are shown inline. For example,
> > if a file containing "This is foo" is changed to "This is bar", the diff
> > will now show "This is " in plain text, "foo" in red, and "bar" in green.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> This looks sooooooooooo strange (and I do not particularly like
> colours, so I am biased).
I thought so, too, after playing around with wdiff. But I do use it
regularly, and it is helpful. It is my equivalent to the word processor
option to show all changes (yes, live and in colour).
> We might want to disable it when the output would not be colored under
> diff.color = auto, at least, but if the user asks to shoot himself in
> the foot that is fine as well ;-).
At the moment, this is _only_ enabled when the user explicitely asks for
it: no --color-words, no word colours. Do you want to be able to say
"git-diff --color-words | patch -p1 -R"?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Add the --color-words option to the diff options family
From: Junio C Hamano @ 2006-07-31 10:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607282354450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this option, the changed words are shown inline. For example,
> if a file containing "This is foo" is changed to "This is bar", the diff
> will now show "This is " in plain text, "foo" in red, and "bar" in green.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This looks sooooooooooo strange (and I do not particularly like
colours, so I am biased). We might want to disable it when the
output would not be colored under diff.color = auto, at least,
but if the user asks to shoot himself in the foot that is fine
as well ;-).
^ permalink raw reply
* Re: [PATCH 2] gitweb: Use list for of open for running git commands, thorougly.
From: Junio C Hamano @ 2006-07-31 10:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200607292251.21072.jnareb@gmail.com>
This, together with PATCH 6, seems to break "history" link.
Visit a repository (summary page), click on "tree" on the second
line, and click on "history" (on any blob or tree).
I might have made a merge mistake while squashing PATCH 2 and
PATCH 6 into a single commit.
BTW, please be careful on trailing whitespaces.
I've wasted quite a lot of time yesterday just fixing up
trailing whitespaces from your patches (although the first in
your series was "whitespace cleanup" X-<).
I usually apply patches with whitespace=strip, unless there is a
compelling reason not to (e.g. when the patch is to add a
testcase of diff output which would inevitably have trailing
whitespaces when a context contains an empty line), which means
if you have a series of patches whose later patch updates lines
with trailing whitespaces an earlier patch introduced the patch
would not apply.
^ permalink raw reply
* Re: git merge (resolve) _is_ stupid
From: Johannes Schindelin @ 2006-07-31 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j1u88ol.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 31 Jul 2006, Junio C Hamano wrote:
> By the way, the "recur" strategy in "next" produces the correct
> result, but it produces a funny error in the middle (that is why
> Johannes is CC'ed).
>
> error: Could not read 0100000000000000000000000000000000000000
I get "0000000100..." ;-) (surprixse her wi1h a big-endian ;-)
The culprit is the call to parse_commit() in merge_bases(). How about
this?
-- 8< --
[PATCH] merge-recur: virtual commits shall never be parsed
It would not make sense to parse a virtual commit, therefore set the
"parsed" flag to 1.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
merge-recursive.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 10bce70..74a329f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -43,6 +43,8 @@ static struct commit *make_virtual_commi
commit->tree = tree;
commit->util = (void*)comment;
*(int*)commit->object.sha1 = virtual_id++;
+ /* avoid warnings */
+ commit->object.parsed = 1;
return commit;
}
--
1.4.2.rc2.gfd00-dirty
^ permalink raw reply related
* Re: git-checkout doesn't understand -- separator
From: Junio C Hamano @ 2006-07-31 10:06 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <eakisg$e6j$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> git-checkout doesn't understand '--' as a separator between <branch> (which
> is optional, but you can always write HEAD), and <path>...
>
> 1144:jnareb@roke:~/git> git checkout HEAD^ -- gitweb/gitweb.cgi
> git-checkout-index: -- is not in the cache
>
> Strange...
Perhaps...
diff --git a/git-checkout.sh b/git-checkout.sh
index 5613bfc..580a9e8 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -67,6 +67,10 @@ while [ "$#" != "0" ]; do
set x "$arg" "$@"
shift
fi
+ case "$1" in
+ --)
+ shift ;;
+ esac
break
;;
esac
^ permalink raw reply related
* Re: [PATCH] pager: config variable pager.color
From: Junio C Hamano @ 2006-07-31 9:53 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: Matthias Lederhofer, git, Johannes Schindelin
In-Reply-To: <17613.50574.56000.861072@lapjr.intranet.kiel.bmiag.de>
Juergen Ruehle <j.ruehle@bmiag.de> writes:
> AFAICS Matthias' patch has the added benefit of moving setup_pager to
> before large files (i.e. packs) are mapped. This helps non-COW-fork
> (i.e. cygwin) tremendously. Actually with Linus' setup refactoring
> this could probably be easily moved to the wrapper,...
Hmph. Never thought about that. Something like this?
-- >8 --
Builtins: control the use of pager from the command table.
This moves the built-in "always-use-pager" logic for log family
to the command dispatch table of git wrapper. This makes it
easier to change the default use of pager, and has an added
benefit that we fork and exec the pager early before packs are
mmapped.
Pointed out by Juergen Ruehle <j.ruehle@bmiag.de>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/builtin-log.c b/builtin-log.c
index 82c69d1..bba1496 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -34,7 +34,6 @@ static int cmd_log_walk(struct rev_info
struct commit *commit;
prepare_revision_walk(rev);
- setup_pager();
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
free(commit->buffer);
diff --git a/git.c b/git.c
index 7321d6c..d031eb9 100644
--- a/git.c
+++ b/git.c
@@ -211,6 +211,7 @@ static int handle_alias(int *argcp, cons
const char git_version_string[] = GIT_VERSION;
#define NEEDS_PREFIX 1
+#define USE_PAGER 2
static void handle_internal_command(int argc, const char **argv, char **envp)
{
@@ -218,13 +219,13 @@ static void handle_internal_command(int
static struct cmd_struct {
const char *cmd;
int (*fn)(int, const char **, const char *);
- int prefix;
+ int option;
} commands[] = {
{ "version", cmd_version },
{ "help", cmd_help },
- { "log", cmd_log, NEEDS_PREFIX },
- { "whatchanged", cmd_whatchanged, NEEDS_PREFIX },
- { "show", cmd_show, NEEDS_PREFIX },
+ { "log", cmd_log, NEEDS_PREFIX | USE_PAGER },
+ { "whatchanged", cmd_whatchanged, NEEDS_PREFIX | USE_PAGER },
+ { "show", cmd_show, NEEDS_PREFIX | USE_PAGER },
{ "push", cmd_push },
{ "format-patch", cmd_format_patch, NEEDS_PREFIX },
{ "count-objects", cmd_count_objects },
@@ -275,8 +276,10 @@ static void handle_internal_command(int
continue;
prefix = NULL;
- if (p->prefix)
+ if (p->option & NEEDS_PREFIX)
prefix = setup_git_directory();
+ if (p->option & USE_PAGER)
+ setup_pager();
if (getenv("GIT_TRACE")) {
int i;
fprintf(stderr, "trace: built-in: git");
^ permalink raw reply related
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Johannes Schindelin @ 2006-07-31 9:38 UTC (permalink / raw)
To: Martin Waitz; +Cc: Luben Tuikov, git
In-Reply-To: <20060731072200.GE16364@admingilde.org>
Hi,
On Mon, 31 Jul 2006, Martin Waitz wrote:
> > I don't like it. While this method works, it is too much effort
> > to have to run make to do this, plus it pollutes your tree.
>
> Do you really think it is that much effort?
> What do others think? alternatives?
I think it is worth it, and it is cleaner. The only drawback: we have to
stuff it somehow into git-instaweb...
Ciao,
Dscho
^ permalink raw reply
* git-checkout doesn't understand -- separator
From: Jakub Narebski @ 2006-07-31 9:35 UTC (permalink / raw)
To: git
git-checkout doesn't understand '--' as a separator between <branch> (which
is optional, but you can always write HEAD), and <path>...
1144:jnareb@roke:~/git> git checkout HEAD^ -- gitweb/gitweb.cgi
git-checkout-index: -- is not in the cache
Strange...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 18] gitweb: Refactor generation of shortlog, tags and heads body
From: Jakub Narebski @ 2006-07-31 9:22 UTC (permalink / raw)
To: git
In-Reply-To: <200607292239.11034.jnareb@gmail.com>
Add git_shortlog_body, git_tags_body and git_heads_body to generate
table with shortlog, tags and heads respectively in git_summary and
git_shortlog, git_tags, git_heads respectively.
Better support for lightweight tags in git_read_refs; currently only
lightweight tag pointing to tag object is not resolved fully.
Shortlog, tags and heads body tables have proper class now (we could
use id instead of class).
Add support for showing full comment on mouseover to tags list when
comment is shortened, similar to how full title of commit was/is
shown on mouseover when title was shortened. Changed layout of tags
table to better show lightweight tags.
Add showing which branch (head) is current branch (current head),
using "current_head" class (we could use id instead).
Corrected "</table\n>" and hit_header_div instead of git_header_div.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Largest patch in the series. Refactoring and unification.
New features (table classes, current head) are fairly unintrusive.
gitweb/gitweb.cgi | 383 ++++++++++++++++++++++++-----------------------------
gitweb/gitweb.css | 10 +
2 files changed, 184 insertions(+), 209 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index dab6068..d209af0 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -1102,6 +1102,10 @@ sub git_read_refs {
$ref_item{'refid'} = $ref_id;
$ref_item{'epoch'} = $co{'committer_epoch'};
$ref_item{'age'} = $co{'age_string'};
+ } else {
+ $ref_item{'reftype'} = $type;
+ $ref_item{'name'} = $ref_file;
+ $ref_item{'refid'} = $ref_id;
}
push @reflist, \%ref_item;
@@ -1111,6 +1115,156 @@ sub git_read_refs {
return \@reflist;
}
+sub git_shortlog_body {
+ # uses global variable $project
+ my ($revlist, $from, $to, $refs, $extra) = @_;
+ $from = 0 unless defined $from;
+ $to = $#{$revlist} if (!defined $to || $#{$revlist} < $to);
+
+ 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 ? git_get_referencing($refs, $commit) : '';
+ my $ref = git_get_referencing($refs, $commit);
+ my %co = git_read_commit($commit);
+ my %ad = date_str($co{'author_epoch'});
+ 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" .
+ "<td>";
+ if (length($co{'title_short'}) < length($co{'title'})) {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"),
+ -class => "list", -title => "$co{'title'}"},
+ "<b>" . esc_html($co{'title_short'}) . "$ref</b>");
+ } else {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"),
+ -class => "list"},
+ "<b>" . esc_html($co{'title'}) . "$ref</b>");
+ }
+ print "</td>\n" .
+ "<td class=\"link\">" .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit")}, "commit") . " | " .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
+ "</td>\n" .
+ "</tr>\n";
+ }
+ if (defined $extra) {
+ print "<tr>\n" .
+ "<td colspan=\"4\">$extra</td>\n" .
+ "</tr>\n";
+ }
+ print "</table>\n";
+}
+
+sub git_tags_body {
+ # uses global variable $project
+ my ($taglist, $from, $to, $extra) = @_;
+ $from = 0 unless defined $from;
+ $to = $#{$taglist} if (!defined $to || $#{$taglist} < $to);
+
+ print "<table class=\"tags\" cellspacing=\"0\">\n";
+ my $alternate = 0;
+ for (my $i = $from; $i <= $to; $i++) {
+ my $entry = $taglist->[$i];
+ my %tag = %$entry;
+ my $comment_lines = $tag{'comment'};
+ my $comment = shift @$comment_lines;
+ my $comment_short;
+ if (defined $comment) {
+ $comment_short = chop_str($comment, 30, 5);
+ }
+ if ($alternate) {
+ print "<tr class=\"dark\">\n";
+ } else {
+ print "<tr class=\"light\">\n";
+ }
+ $alternate ^= 1;
+ print "<td><i>$tag{'age'}</i></td>\n" .
+ "<td>" .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}"),
+ -class => "list"}, "<b>" . esc_html($tag{'name'}) . "</b>") .
+ "</td>\n" .
+ "<td>";
+ if (defined $comment) {
+ if (length($comment_short) < length($comment)) {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}"),
+ -class => "list", -title => $comment}, $comment_short);
+ } else {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}"),
+ -class => "list"}, $comment);
+ }
+ }
+ print "</td>\n" .
+ "<td class=\"selflink\">";
+ if ($tag{'type'} eq "tag") {
+ print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, "tag");
+ } else {
+ print " ";
+ }
+ print "</td>\n" .
+ "<td class=\"link\">" . " | " .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}")}, $tag{'reftype'});
+ if ($tag{'reftype'} eq "commit") {
+ print " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
+ " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'refid'}")}, "log");
+ } elsif ($tag{'reftype'} eq "blob") {
+ print " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=blob_plain;h=$tag{'refid'}")}, "raw");
+ }
+ print "</td>\n" .
+ "</tr>";
+ }
+ if (defined $extra) {
+ print "<tr>\n" .
+ "<td colspan=\"5\">$extra</td>\n" .
+ "</tr>\n";
+ }
+ print "</table>\n";
+}
+
+sub git_heads_body {
+ # uses global variable $project
+ my ($taglist, $head, $from, $to, $extra) = @_;
+ $from = 0 unless defined $from;
+ $to = $#{$taglist} if (!defined $to || $#{$taglist} < $to);
+
+ print "<table class=\"heads\" cellspacing=\"0\">\n";
+ my $alternate = 0;
+ for (my $i = $from; $i <= $to; $i++) {
+ my $entry = $taglist->[$i];
+ my %tag = %$entry;
+ my $curr = $tag{'id'} eq $head;
+ if ($alternate) {
+ print "<tr class=\"dark\">\n";
+ } else {
+ print "<tr class=\"light\">\n";
+ }
+ $alternate ^= 1;
+ print "<td><i>$tag{'age'}</i></td>\n" .
+ ($tag{'id'} eq $head ? "<td class=\"current_head\">" : "<td>") .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}"),
+ -class => "list"}, "<b>" . esc_html($tag{'name'}) . "</b>") .
+ "</td>\n" .
+ "<td class=\"link\">" .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") . " | " .
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'name'}")}, "log") .
+ "</td>\n" .
+ "</tr>";
+ }
+ if (defined $extra) {
+ print "<tr>\n" .
+ "<td colspan=\"3\">$extra</td>\n" .
+ "</tr>\n";
+ }
+ print "</table>\n";
+}
+
sub git_summary {
my $descr = git_read_description($project) || "none";
my $head = git_read_head($project);
@@ -1139,138 +1293,36 @@ sub git_summary {
my $refs = read_info_ref();
git_header_html();
git_page_nav('summary','', $head);
+
print "<div class=\"title\"> </div>\n";
print "<table cellspacing=\"0\">\n" .
"<tr><td>description</td><td>" . esc_html($descr) . "</td></tr>\n" .
"<tr><td>owner</td><td>$owner</td></tr>\n" .
"<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
"</table>\n";
+
open my $fd, "-|", $GIT, "rev-list", "--max-count=17", git_read_head($project)
or die_error(undef, "Open git-rev-list failed.");
my @revlist = map { chomp; $_ } <$fd>;
close $fd;
git_header_div('shortlog');
- my $i = 16;
- print "<table cellspacing=\"0\">\n";
- my $alternate = 0;
- foreach my $commit (@revlist) {
- my %co = git_read_commit($commit);
- my %ad = date_str($co{'author_epoch'});
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- if ($i-- > 0) {
- my $ref = git_get_referencing($refs, $commit);
- print "<td><i>$co{'age_string'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
- "<td>";
- if (length($co{'title_short'}) < length($co{'title'})) {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
- "<b>" . esc_html($co{'title_short'}) . "$ref</b>");
- } else {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list"},
- "<b>" . esc_html($co{'title'}) . "$ref</b>");
- }
- print "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit")}, "commit") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
- "</td>\n" .
- "</tr>";
- } else {
- print "<td>" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog")}, "...") . "</td>\n" .
- "</tr>";
- last;
- }
- }
- print "</table\n>";
+ git_shortlog_body(\@revlist, 0, 15, $refs,
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog")}, "..."));
my $taglist = git_read_refs("refs/tags");
if (defined @$taglist) {
git_header_div('tags');
- my $i = 16;
- print "<table cellspacing=\"0\">\n";
- my $alternate = 0;
- foreach my $entry (@$taglist) {
- my %tag = %$entry;
- my $comment_lines = $tag{'comment'};
- my $comment = shift @$comment_lines;
- if (defined($comment)) {
- $comment = chop_str($comment, 30, 5);
- }
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- if ($i-- > 0) {
- print "<td><i>$tag{'age'}</i></td>\n" .
- "<td>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}"), -class => "list"},
- "<b>" . esc_html($tag{'name'}) . "</b>") .
- "</td>\n" .
- "<td>";
- if (defined($comment)) {
- print $cgi->a({-class => "list", -href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, esc_html($comment));
- }
- print "</td>\n" .
- "<td class=\"link\">";
- if ($tag{'type'} eq "tag") {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, "tag") . " | ";
- }
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}")}, $tag{'reftype'});
- if ($tag{'reftype'} eq "commit") {
- print " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'refid'}")}, "log");
- }
- print "</td>\n" .
- "</tr>";
- } else {
- print "<td>" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tags")}, "...") . "</td>\n" .
- "</tr>";
- last;
- }
- }
- print "</table\n>";
+ git_tags_body($taglist, 0, 15,
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tags")}, "..."));
}
my $headlist = git_read_refs("refs/heads");
if (defined @$headlist) {
git_header_div('heads');
- my $i = 16;
- print "<table cellspacing=\"0\">\n";
- my $alternate = 0;
- foreach my $entry (@$headlist) {
- my %tag = %$entry;
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- if ($i-- > 0) {
- print "<td><i>$tag{'age'}</i></td>\n" .
- "<td>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}"), -class => "list"},
- "<b>" . esc_html($tag{'name'}) . "</b>") .
- "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'name'}")}, "log") .
- "</td>\n" .
- "</tr>";
- } else {
- print "<td>" . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=heads")}, "...") . "</td>\n" .
- "</tr>";
- last;
- }
- }
- print "</table\n>";
+ git_heads_body($taglist, $head, 0, 15,
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=heads")}, "..."));
}
+
git_footer_html();
}
@@ -1472,48 +1524,11 @@ sub git_tags {
git_header_html();
git_page_nav('','', $head,undef,$head);
git_header_div('summary', $project);
- print "<table cellspacing=\"0\">\n";
my $taglist = git_read_refs("refs/tags");
- my $alternate = 0;
if (defined @$taglist) {
- foreach my $entry (@$taglist) {
- my %tag = %$entry;
- my $comment_lines = $tag{'comment'};
- my $comment = shift @$comment_lines;
- if (defined($comment)) {
- $comment = chop_str($comment, 30, 5);
- }
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- print "<td><i>$tag{'age'}</i></td>\n" .
- "<td>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}"), -class => "list"},
- "<b>" . esc_html($tag{'name'}) . "</b>") .
- "</td>\n" .
- "<td>";
- if (defined($comment)) {
- print $cgi->a({-class => "list", -href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, $comment);
- }
- print "</td>\n" .
- "<td class=\"link\">";
- if ($tag{'type'} eq "tag") {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=tag;h=$tag{'id'}")}, "tag") . " | ";
- }
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=$tag{'reftype'};h=$tag{'refid'}")}, $tag{'reftype'});
- if ($tag{'reftype'} eq "commit") {
- print " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'refid'}")}, "log");
- }
- print "</td>\n" .
- "</tr>";
- }
+ git_tags_body($taglist);
}
- print "</table\n>";
git_footer_html();
}
@@ -1521,32 +1536,13 @@ sub git_heads {
my $head = git_read_head($project);
git_header_html();
git_page_nav('','', $head,undef,$head);
- hit_header_div('summary', $project);
- print "<table cellspacing=\"0\">\n";
+ git_header_div('summary', $project);
my $taglist = git_read_refs("refs/heads");
my $alternate = 0;
if (defined @$taglist) {
- foreach my $entry (@$taglist) {
- my %tag = %$entry;
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- print "<td><i>$tag{'age'}</i></td>\n" .
- "<td>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}"), -class => "list"}, "<b>" . esc_html($tag{'name'}) . "</b>") .
- "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$tag{'name'}")}, "shortlog") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=log;h=$tag{'name'}")}, "log") .
- "</td>\n" .
- "</tr>";
- }
+ git_heads_body($taglist, $head);
}
- print "</table\n>";
git_footer_html();
}
@@ -2544,48 +2540,19 @@ sub git_shortlog {
close $fd;
my $paging_nav = git_get_paging_nav('shortlog', $hash, $head, $page, $#revlist);
+ my $next_link = '';
+ if ($#revlist >= (100 * ($page+1)-1)) {
+ $next_link =
+ $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$hash;pg=" . ($page+1)),
+ -title => "Alt-n"}, "next");
+ }
+
git_header_html();
git_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
git_header_div('summary', $project);
- print "<table cellspacing=\"0\">\n";
- my $alternate = 0;
- for (my $i = ($page * 100); $i <= $#revlist; $i++) {
- my $commit = $revlist[$i];
- my $ref = git_get_referencing($refs, $commit);
- my %co = git_read_commit($commit);
- my %ad = date_str($co{'author_epoch'});
- if ($alternate) {
- print "<tr class=\"dark\">\n";
- } else {
- print "<tr class=\"light\">\n";
- }
- $alternate ^= 1;
- print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
- "<td>";
- if (length($co{'title_short'}) < length($co{'title'})) {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list", -title => "$co{'title'}"},
- "<b>" . esc_html($co{'title_short'}) . "$ref</b>");
- } else {
- print $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit"), -class => "list"},
- "<b>" . esc_html($co{'title_short'}) . "$ref</b>");
- }
- print "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commit;h=$commit")}, "commit") .
- " | " . $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=commitdiff;h=$commit")}, "commitdiff") .
- "</td>\n" .
- "</tr>";
- }
- if ($#revlist >= (100 * ($page+1)-1)) {
- print "<tr>\n" .
- "<td>" .
- $cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=shortlog;h=$hash;pg=" . ($page+1)), -title => "Alt-n"}, "next") .
- "</td>\n" .
- "</tr>\n";
- }
- print "</table\n>";
+ git_shortlog_body(\@revlist, ($page * 100), $#revlist, $refs, $next_link);
+
git_footer_html();
}
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index fffdb13..460e728 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -181,12 +181,16 @@ td {
vertical-align: top;
}
-td.link {
+td.link, td.selflink {
padding: 2px 5px;
font-family: sans-serif;
font-size: 10px;
}
+td.selflink {
+ padding-right: 0px;
+}
+
td.sha1 {
font-family: monospace;
}
@@ -196,6 +200,10 @@ td.error {
background-color: yellow;
}
+td.current_head {
+ text-decoration: underline;
+}
+
table.diff_tree span.file_status.new {
color: #008000;
}
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] pager: config variable pager.color
From: Juergen Ruehle @ 2006-07-31 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git, Johannes Schindelin
In-Reply-To: <7vd5bmbo46.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> Why? The three users of cmd_log_walk() need to call setup_pager()
> >> explicitely, when cmd_log_walk() can do it for them?
> >
> > The explanation is below the commit message:
> > "setup_pager has to be called before git_diff_ui_config because the
> > latter uses pager_use_color initialized by setup_pager."
>
> If that is the reason, perhaps we could restructure the setting
> and use of of diff_use_color_default like the attached, which
> would be cleaner.
AFAICS Matthias' patch has the added benefit of moving setup_pager to
before large files (i.e. packs) are mapped. This helps non-COW-fork
(i.e. cygwin) tremendously. Actually with Linus' setup refactoring
this could probably be easily moved to the wrapper, but I'm too stupid
so I just deleted setup_pager from my version:-)
jr
^ permalink raw reply
* git merge (resolve) _is_ stupid
From: Junio C Hamano @ 2006-07-31 8:44 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
While dealing with Jakub's gitweb changes, I found that merge we
use _is_ very stupid. Perhaps it is not a surprise...
My "next" was at 688a750, and "master" was at b63fafd. I had
already merged gitweb changes from Luben to "master" at this
point, and "next" was in sync with "master" with respect to
gitweb/, i.e. this gave empty:
$ git diff master next gitweb/
Jakub's gitweb changes were stored in jn/web branch which
contained 16 patches on top of "master".
However, pulling "jn/web" (594e212) into "next" using resolve
strategy produced interesting conflicts. Essentially, it said
that some changes done by Luben (which has already merged to
"master" and precedes what Jakub did in "jn/web") conflict with
what "jn/web" does, which is quite bogus.
This merge has three merge-bases, but
$ git log master..next -- gitweb/
shows only two merges, and that is not so surprising given that
at this point gitweb/ files are identical between master and
next.
More interestingly, if I merge "master" to "next" first and then
merge "jn/web" on top of the result, the resolve strategy does
the right thing. This is understandable -- by merging "master"
into "next", merge base between "next" and "jn/web" becomes
"master" and nothing else.
Using recursive strategy resolved this merge correctly, taking
gitweb/ files from "jn/web" branch.
By the way, the "recur" strategy in "next" produces the correct
result, but it produces a funny error in the middle (that is why
Johannes is CC'ed).
error: Could not read 0100000000000000000000000000000000000000
: gitster; git merge -s recur 'test merge' next jn/web
Merging next with 594e212bc849039a204deef1d16c2eddcc451532
Merging:
688a75071490101dbc660e3304aafb7a13e28807 Merge branch '__/setup-n-mv' into next
594e212bc849039a204deef1d16c2eddcc451532 gitweb: Ref refactoring - use git_get_referencing for marking tagged/head commits
found 3 common ancestor(s):
7061cf0f205e86613c3a3306fdfedf2a5dcc8a65 Merge branch 'lt/setup' into __/setup-n-mv
acb0f6f33760b43c1fc9617a45346ab3738f021a gitweb.cgi: git_blame2: slight optimization reading the blame lines
2d023581c9a0ae5efdebfd0084d54d09669a25d5 Set datarootdir in config.mak.in
Merging:
7061cf0f205e86613c3a3306fdfedf2a5dcc8a65 Merge branch 'lt/setup' into __/setup-n-mv
acb0f6f33760b43c1fc9617a45346ab3738f021a gitweb.cgi: git_blame2: slight optimization reading the blame lines
found 1 common ancestor(s):
634331061599a82968daddae2d2c0896b6137d4c gitweb.cgi: Centralize printing of the page path
Auto-merging gitweb/gitweb.cgi
Merging:
virtual merged tree
2d023581c9a0ae5efdebfd0084d54d09669a25d5 Set datarootdir in config.mak.in
error: Could not read 0100000000000000000000000000000000000000
found 1 common ancestor(s):
7b8cf0cf2973cc8df3bdd36b9b36542b1f04d70a Rename man1 and man7 variables to man1dir and man7dir
Auto-merging .gitignore
Auto-merging INSTALL
Auto-merging Makefile
Auto-merging Makefile
Merge made by recur.
Documentation/git-tar-tree.txt | 5
Makefile | 3
git.c | 76 ++---
gitweb/gitweb.cgi | 609 +++++++++++++++++-----------------------
setup.c | 4
5 files changed, 300 insertions(+), 397 deletions(-)
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Luben Tuikov @ 2006-07-31 8:14 UTC (permalink / raw)
To: Junio C Hamano, Martin Waitz; +Cc: git
In-Reply-To: <7vzmeqa7tx.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.pl
> > similarity index 100%
> > rename from gitweb/gitweb.cgi
> > rename to gitweb/gitweb.pl
> > index 243a2921f849568260e848201d238b3b9fe7e1f2..8e05c335f801d4c52a9b348fa56fccfae36ce621
> 100755
> > --- a/gitweb/gitweb.cgi
> > +++ b/gitweb/gitweb.pl
> > @@ -24,14 +24,14 @@ our $rss_link = "";
> >
> > # core git executable to use
> > # this can just be "git" if your webserver has a sensible PATH
> > -our $GIT = "/usr/bin/git";
> > +our $GIT = "@@GIT_BINDIR@@/git";
> >
> > # absolute fs-path which will be prepended to the project path
> > #our $projectroot = "/pub/scm";
> > -our $projectroot = "/home/kay/public_html/pub/scm";
> > +our $projectroot = "@@GITWEB_PROJECTROOT@@";
> >
> > # version of the core git binary
> > -our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> > +our $git_version = "@@GIT_VERSION@@";
>
> I think the other parts are sensible but I am not sure if we
> want to report the version of git distribution (your patch), or
> the version of git binary the cgi script happens to use (the
> current implementation).
I'd rather see git distribution (Martin's patch) since, after all,
gitweb became part of git not so long ago. And as thus, its own
numbers don't matter much, but the git distribution.
In fact, I was thinking of submitting a patch to the same effect
myself.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Jakub Narebski @ 2006-07-31 7:38 UTC (permalink / raw)
To: git
In-Reply-To: <20060731070819.GD16364@admingilde.org>
Martin Waitz wrote:
> On Sun, Jul 30, 2006 at 06:20:26PM -0700, Junio C Hamano wrote:
>>
>> I think the other parts are sensible but I am not sure if we
>> want to report the version of git distribution (your patch), or
>> the version of git binary the cgi script happens to use (the
>> current implementation).
>
> hmm, right.
> Well, now that gitweb is included with GIT I think that they will
> be in sync on many sites, but of course that's not guaranteed.
>
> Shall I send a new patch without that change?
There are currently two version variables in gitweb: the version of the
script, and the version of git binaries used. They might be different.
But now that gitweb is bundled with git, perhaps we could use compile-time
git version as gitweb version, i.e.
our $version = "@@GIT_VERSION@@";
while leaving $git_version as is, i.e.
our $git_version =
qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown"
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Martin Waitz @ 2006-07-31 7:22 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060731035737.24181.qmail@web31803.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]
hoi :)
thanks for the feedback!
> I don't like it. While this method works, it is too much effort
> to have to run make to do this, plus it pollutes your tree.
Do you really think it is that much effort?
What do others think? alternatives?
> Instead, what you can do is make gitweb.cgi read a text file
> from . which has those variables defined.
I don't really care if it is a configuration file or a build-time
configuration, but I need something now.
If you submit your proposal, we can compare both and choose the best
one ;-).
> This way, I can just copy gitweb.cgi into my web-server directory
> and voila it works, since the variable definition file would
> always be there. This way:
> - no need to run make to build "gitweb.cgi" or "gitweb.pl" whatever
> you call it,
ok, but you have to call make anyway to build the rest of GIT,
so this shouldn't be a big problem.
> - no need to pollute your tree with site defined variables,
this is achieved by my patch, too.
> - simple copy (cp) would install a working version, instead of
> the current cp + patch with local settings method.
this is achieved by my patch, too.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* (unsolicited hint) resolving conflicts early
From: Junio C Hamano @ 2006-07-31 7:19 UTC (permalink / raw)
To: git
In a work flow that employs multiple topic branches, sometimes I
find that unrelated topics need to touch the same area of the
code, or they do not have textual conflicts but still have
semantic interactions. The topic branch workflow wants you to
merge each topic at least twice (once while testing and another
time when you declare topic to be ready), which means you would
need to resolve the same conflict at least twice.
Here is a trick I've been using to deal with such a case.
A quick refresher course of "topic branch" workflow:
- you branch off from your primary branch (typically "master")
and create one branch per development topic.
- your development takes place on the topic branches.
- each topic can (and should) be tested alone, but you would
want to test them as a whole in order to make sure your
topics mesh together well. Typically you use a branch other
than your primary branch to merge them all and use the result
for testing. Depending on your taste, this test branch could
be throw-away, or long lived (e.g. my "pu" is throw-away, as
opposed to "next" which is a long-lived test branch).
- When a topic becomes fully cooked, you merge it into your
primary branch.
When two logically independent topics need to touch the same
area of code, or have semantic interactions that do not
necessarily involve textual merge conflicts, they need to be
resolved when the topics are merged into the test branch.
You would not know which topic becomes ready to be merged to
your primary branch first, but eventually you would want to have
both of them graduate to your mainline. So when you merge the
second topic into your mainline, you would need to resolve the
same conflict you resolved when you merged it to the test branch.
However, it is not easy to "reuse" the merge resolution. rerere
helps you reuse textual conflict resolution, but fixups needed
that do not involve textual conflicts are not handled by
"rerere".
For example, I have "lt/setup" that restructures calls to
setup_git_directory(), and "js/mv" that introduces a new
built-in implementation of "git mv". They both touch the
command table in git.c which causes textual conflicts, and the
former changes the calling convention of all built-in command
implementations, so builtin-mv.c::cmd_mv() (which does not have
any textual conflict) needs to be modified when these two
branches are used together.
The way I solve this is to use the third branch ("conflict
resolution branch between the two topic branches"). You branch
this off of one of the topic branches and merge in the other,
and resolve conflicts there. For example, I have __/setup-n-mv
branch which merges lt/setup and js/mv, and that branch is what
is merged into "next" (the test branch):
$ git checkout -b __/setup-n-mv lt/setup
$ git pull . js/mv
... fix textual merge conflicts here.
... compile testing reveals that further fixups are needed;
... fix them up here as well.
... this can become an "evil merge", or a separate
... "fixup" commit can be made in this resolution branch.
$ git commit -a
$ git checkout next ; git pull . __/setup-n-mv
When one of the branches is ready to be merged to "master", I
can just do so. After that, I merge the conflict resolution
branch into the other topic. This way, when the other one
graduates, the merge conflict is already resolved and the
merging into "master" becomes quite easy.
A good thing here is that it is a lot easier to see what
interactions the topics have while merging them to "next" for
testing than later merging the first and then sometime later
merging the second topic to "master", because the former happens
soon after I take patches to the topic branch (or I work on the
topic myself). Merging the second branch to "master" happens
much later, at which point I may need to do extra work to
remember the details of what interactions the topics had and
what were needed to resolve them (not just textually but
semantically).
HTH ;-).
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Martin Waitz @ 2006-07-31 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmeqa7tx.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
hoi :)
On Sun, Jul 30, 2006 at 06:20:26PM -0700, Junio C Hamano wrote:
> I think the other parts are sensible but I am not sure if we
> want to report the version of git distribution (your patch), or
> the version of git binary the cgi script happens to use (the
> current implementation).
hmm, right.
Well, now that gitweb is included with GIT I think that they will
be in sync on many sites, but of course that's not guaranteed.
Shall I send a new patch without that change?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: use out-of-line GIT logo.
From: Martin Waitz @ 2006-07-31 7:02 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060731035904.53458.qmail@web31813.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
hoi :)
On Sun, Jul 30, 2006 at 08:59:04PM -0700, Luben Tuikov wrote:
> --- Martin Waitz <tali@admingilde.org> wrote:
>
> > Use the normal web server instead of the CGI to provide the git logo,
> > just like the gitweb.css.
>
> NACK. I'd really rather keep the logo (which is essential) in the
> file itself. This would mean one less file to worry about.
we could default to use git-logo.png from kernel.org if you care about
easy home installations.
For each serious gitweb site it should not be a problem to put the logo
into their image folder.
And I really think that the .css is much more essential then the logo
;-). So perhaps use kernel.org for the .css by default, too?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Jakub Narebski @ 2006-07-31 6:55 UTC (permalink / raw)
To: git
In-Reply-To: <20060730223754.GA16364@admingilde.org>
Martin Waitz wrote:
> gitweb/{gitweb.cgi => gitweb.pl} | 15 +++++++--------
[...]
> diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.pl
> similarity index 100%
> rename from gitweb/gitweb.cgi
> rename to gitweb/gitweb.pl
> index 243a2921f849568260e848201d238b3b9fe7e1f2..8e05c335f801d4c52a9b348fa56fccfae36ce621 100755
> --- a/gitweb/gitweb.cgi
> +++ b/gitweb/gitweb.pl
Shouldn't we use .perl suffix, i.e. gitweb.perl, like almost all
other Perl files in git distribution (the exception is
Documentation/sort_glossary.pl which never get installed).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-diff between /dev/null and blob
From: Junio C Hamano @ 2006-07-31 6:50 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <eajl4r$b7o$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Currently, due to artifact of git-diff argument parsing you can get diff
> of two arbitrary blobs given by their sha1 id, e.g.
> git diff ab8050ceb4e43522e858768cc2c02fcb91839370 fd05278808d458602587bb024a48726018d30926
Just FYI, it is pretty much by design not artifact to allow
something like this:
git diff master:Makefile next:Makefile
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Junio C Hamano @ 2006-07-31 6:41 UTC (permalink / raw)
To: ltuikov; +Cc: git, Martin Waitz
In-Reply-To: <20060731035737.24181.qmail@web31803.mail.mud.yahoo.com>
-
Luben Tuikov <ltuikov@yahoo.com> writes:
> -- Martin Waitz <tali@admingilde.org> wrote:
>> Generate gitweb/gitweb.cgi to reduce the need to patch gitweb.cgi by
>> the end user.
>> The GIT installation directory and version are already known by the
>> Makefile, they can be inserted directly into gitweb.
>> All other gitweb configuration parameters can now be specified
>> by providing GITWEB_* variables while building GIT.
>> These are described in gitweb/README.
>
> NACK.
>
> I don't like it. While this method works, it is too much effort
> to have to run make to do this, plus it pollutes your tree.
I do not quite agree with this reasoning. With that definition
of "polluting your tree", all build of git-*.{sh,perl,py} are
polluting your tree. If compile/install time customization is
handier I do not have problem doing it that way.
> Instead, what you can do is make gitweb.cgi read a text file
> from . which has those variables defined.
I think there was a discussion on having a configuration file
for gitweb (not per-repository .git/config but installation wide
configuration file). If I recall correctly, the killer argument
against it was that you would need to bootstrap the process by
somehow telling gitweb.cgi where to read from that configuration
file, and if you are going to customize gitweb.cgi before
installation for the site that way, then giving a bit more
configuration in gitweb.cgi (like Martin did in the patch we are
discussion) is simpler.
> - no need to run make to build "gitweb.cgi" or "gitweb.pl" whatever
> you call it,
> - no need to pollute your tree with site defined variables,
> - simple copy (cp) would install a working version, instead of
> the current cp + patch with local settings method.
While I agree all of these "no need to" makes things slightly
simpler, I do not think it is such a big deal -- we are building
git-*.{sh,perl,py,c} anyway.
^ permalink raw reply
* Re: [PATCH] gitweb: use out-of-line GIT logo.
From: Jakub Narebski @ 2006-07-31 5:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060731035904.53458.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Martin Waitz <tali@admingilde.org> wrote:
>
>> Use the normal web server instead of the CGI to provide the git logo,
>> just like the gitweb.css.
>
> NACK. I'd really rather keep the logo (which is essential) in the
> file itself. This would mean one less file to worry about.
I'm not sure. On the one hand this introduces yet another file which we have
to worry about, on the other it probably help performance. Any hard
numbers?
The difference with gitweb.css is that you edit gitweb.css, and that
inclused CSS can be cached; we could probably do the same trick like with
logo (i.e. embed it in gitweb.css, but still use
<link rel="stylesheet" type="text/css" href="$my_uri?a=gitweb.css"/>
and not
<style type="text/css">
...
</style>
Besides, mixed language files are hard to syntax highlight correctly...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Java GIT/Eclipse GIT version 0.1.1
From: Shawn Pearce @ 2006-07-31 4:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607301047150.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Fri, 28 Jul 2006, Shawn Pearce wrote:
>
> > I would appreciate any and all input, feedback, etc. that anyone
> > might have on this library or plugin. Patches are of course
> > certainly welcome. :-)
>
> I'm going to try to do a Servlet (+ my stuff) implementation of essentiall
> gitweb, with the idea that it could integrate with project management
> software (i.e., link completed tasks to the commit which completed them,
> regressions to the commit that broke things, fixes to the commit that
> fixed them, etc, with the UI for choosing values letting you browse the
> actual content and validating that the hash you give exists).
>
> I don't think I need anything you don't already have, but I'll write
> documentation as I figure out what's going on, if you want that.
Sure. Any improvements would be welcome. :-)
Please keep in mind that when I post the next update to the
repository I'm going to switch the license to the LGPL.
Apparently the Apache License has issues with GPL (I didn't know
this until just recently) and the GPL is definately incompatible
with the Eclipse license (also just found this out).
--
Shawn.
^ 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