* [PATCH] gitweb: Paginate commit/author/committer search output
From: Robert Fitzsimons @ 2006-12-23 14:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robert Fitzsimons, git
In-Reply-To: <200612231400.18774.jnareb@gmail.com>
Paginate commit/author/committer search output to only show 100 commits
at a time, added appropriate nav links.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
> Although with search you have additional complication with marking match,
> and "log" view like rather than "shortlog" like view... so I'm not sure
> if it would truly help. On the other hand you can use --skip option you
> have introduced...
I used the slower non--skip workflow for the moment, so at least there
is no need to upgrade the core git commands.
Robert
gitweb/gitweb.perl | 148 ++++++++++++++++++++++++++++++++++++----------------
1 files changed, 103 insertions(+), 45 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6bd0c..e4378b9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2837,6 +2837,58 @@ sub git_heads_body {
print "</table>\n";
}
+sub git_search_grep_body {
+ my ($greplist, $from, $to, $extra) = @_;
+ $from = 0 unless defined $from;
+ $to = $#{$greplist} if (!defined $to || $#{$greplist} < $to);
+
+ print "<table class=\"grep\" cellspacing=\"0\">\n";
+ my $alternate = 1;
+ for (my $i = $from; $i <= $to; $i++) {
+ my $commit = $greplist->[$i];
+ my %co = parse_commit($commit);
+ if (!%co) {
+ next;
+ }
+ 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'}, 15, 5)) . "</i></td>\n" .
+ "<td>" .
+ $cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
+ esc_html(chop_str($co{'title'}, 50)) . "<br/>");
+ my $comment = $co{'comment'};
+ foreach my $line (@$comment) {
+ if ($line =~ m/^(.*)($searchtext)(.*)$/i) {
+ my $lead = esc_html($1) || "";
+ $lead = chop_str($lead, 30, 10);
+ my $match = esc_html($2) || "";
+ my $trail = esc_html($3) || "";
+ $trail = chop_str($trail, 30, 10);
+ my $text = "$lead<span class=\"match\">$match</span>$trail";
+ print chop_str($text, 80, 5) . "<br/>\n";
+ }
+ }
+ print "</td>\n" .
+ "<td class=\"link\">" .
+ $cgi->a({-href => href(action=>"commit", hash=>$co{'id'})}, "commit") .
+ " | " .
+ $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$co{'id'})}, "tree");
+ print "</td>\n" .
+ "</tr>\n";
+ }
+ if (defined $extra) {
+ print "<tr>\n" .
+ "<td colspan=\"3\">$extra</td>\n" .
+ "</tr>\n";
+ }
+ print "</table>\n";
+}
+
## ======================================================================
## ======================================================================
## actions
@@ -4154,6 +4206,9 @@ sub git_search {
if (!%co) {
die_error(undef, "Unknown commit object");
}
+ if (!defined $page) {
+ $page = 0;
+ }
$searchtype ||= 'commit';
if ($searchtype eq 'pickaxe') {
@@ -4166,11 +4221,7 @@ sub git_search {
}
git_header_html();
- git_print_page_nav('','', $hash,$co{'tree'},$hash);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
- print "<table cellspacing=\"0\">\n";
- my $alternate = 1;
if ($searchtype eq 'commit' or $searchtype eq 'author' or $searchtype eq 'committer') {
my $greptype;
if ($searchtype eq 'commit') {
@@ -4180,52 +4231,58 @@ sub git_search {
} elsif ($searchtype eq 'committer') {
$greptype = "--committer=";
}
- $/ = "\0";
open my $fd, "-|", git_cmd(), "rev-list",
- "--header", "--parents", ($greptype . $searchtext),
- $hash, "--"
+ ("--max-count=" . (100 * ($page+1))),
+ ($greptype . $searchtext),
+ $hash, "--"
or next;
- while (my $commit_text = <$fd>) {
- my @commit_lines = split "\n", $commit_text;
- my %co = parse_commit(undef, \@commit_lines);
- if (!%co) {
- next;
- }
- 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'}, 15, 5)) . "</i></td>\n" .
- "<td>" .
- $cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
- esc_html(chop_str($co{'title'}, 50)) . "<br/>");
- my $comment = $co{'comment'};
- foreach my $line (@$comment) {
- if ($line =~ m/^(.*)($searchtext)(.*)$/i) {
- my $lead = esc_html($1) || "";
- $lead = chop_str($lead, 30, 10);
- my $match = esc_html($2) || "";
- my $trail = esc_html($3) || "";
- $trail = chop_str($trail, 30, 10);
- my $text = "$lead<span class=\"match\">$match</span>$trail";
- print chop_str($text, 80, 5) . "<br/>\n";
- }
- }
- print "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"commit", hash=>$co{'id'})}, "commit") .
- " | " .
- $cgi->a({-href => href(action=>"tree", hash=>$co{'tree'}, hash_base=>$co{'id'})}, "tree");
- print "</td>\n" .
- "</tr>\n";
- }
+ my @revlist = map { chomp; $_ } <$fd>;
close $fd;
+
+ my $paging_nav = '';
+ if ($page > 0) {
+ $paging_nav .=
+ $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$searchtext, searchtype=>$searchtype)},
+ "first");
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"search", hash=>$hash,
+ searchtext=>$searchtext, searchtype=>$searchtype,
+ 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=>"search", hash=>$hash,
+ searchtext=>$searchtext, searchtype=>$searchtype,
+ 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=>"search", hash=>$hash,
+ searchtext=>$searchtext, searchtype=>$searchtype,
+ page=>$page+1),
+ -accesskey => "n", -title => "Alt-n"}, "next");
+ }
+
+ git_print_page_nav('','', $hash,$co{'tree'},$hash, $paging_nav);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_search_grep_body(\@revlist, ($page * 100), $#revlist, $next_link);
}
if ($searchtype eq 'pickaxe') {
+ git_print_page_nav('','', $hash,$co{'tree'},$hash);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash);
+
+ print "<table cellspacing=\"0\">\n";
+ my $alternate = 1;
$/ = "\n";
my $git_command = git_cmd_str();
open my $fd, "-|", "$git_command rev-list $hash | " .
@@ -4280,8 +4337,9 @@ sub git_search {
}
}
close $fd;
+
+ print "</table>\n";
}
- print "</table>\n";
git_footer_html();
}
--
1.4.4.3.gae7ae3
^ permalink raw reply related
* Re: [RFC] git reflog show
From: Johannes Schindelin @ 2006-12-23 14:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v4prmsxjl.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 23 Dec 2006, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I'm toying with what a 'git reflog show' might look like. I attached
> > the prototype code below. Here's the output from the recent part of
> > my mmap pack window topic:
> >
> > $ ./git-reflog show refs/heads/sp/mapwin
> > ...clipped for space...
> >
>
> The output should look almost the same as "git log" for the part
> that represents a series of normal branch activity where commits
> are built up one-by-one. I think it would be useful if you can
> somehow make parts that are _not_ linear stand out and perhaps
> allow omitting a stretch of ordinary single strand of pearls.
I wonder if it would make sense to teach the revision walking machinery
about reflogs. A commit could be marked as coming from a reflog entry, and
in that case the parents could be determined by the reflog rather than the
commit itself.
Is this a stupid idea?
Ciao,
Dscho
^ permalink raw reply
* Re: author/commit counts
From: Nicolas Pitre @ 2006-12-23 14:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randy Dunlap, git
In-Reply-To: <Pine.LNX.4.63.0612231521340.19693@wbgn013.biozentrum.uni-wuerzburg.de>
On Sat, 23 Dec 2006, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 23 Dec 2006, Nicolas Pitre wrote:
>
> > git log --author=<blah> | git shortlog -s
>
> Note that the builtin shortlog reuses the fine revision walking machinery:
>
> git shortlog --author=<blah> -n -s
>
> works like a charm.
I know and use it myself. But many people might not have a recent
enough git version for that.
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Johannes Schindelin @ 2006-12-23 14:28 UTC (permalink / raw)
To: git
In-Reply-To: <20061223023719.GA8734@spearce.org>
Shawn Pearce <spearce <at> spearce.org> writes:
> $ git log | grep ^Author | cut -d\< -f1 | sort \
> | uniq -c | sort -n -r | head -20
As Junio pointed out in another mail, "git shortlog -n -s | head -20" is
shorter...
> You can also see the very clear gap between Junio and the rest of the
> world. There's very little dispute about who really codes Git.
Note that this still holds when doing the technically correct thing:
$ git shortlog -n -s --no-merges
Ciao,
Dscho
^ permalink raw reply
* Re: branch.<name>.merge specifying remote branch name
From: Jakub Narebski @ 2006-12-23 14:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612230924110.18171@xanadu.home>
Nicolas Pitre wrote:
> On Sat, 23 Dec 2006, Jakub Narebski wrote:
>
>> About the discussion about branch.<name>.merge specifying remote branch name
>> and relative merits of specifying remote branch name (without need for
>> tracking branch), and local branch name (which is supposedly more user
>> friendly, and branch name specifies also remote usually)...
>>
>> Perhaps it is time to resurrect branch.<name>.mergeLocal (or localMerge)
>> idea, and both sides would be happy (well, at least when one would code
>> it ;-).
>
> Adding more and more options doesn't make it friendlier to use.
>
> Why couldn't both names (local and remote) be accepted by
> branch.blah.merge?
Junio just implemented that. Although it is a bit of magic (which can bite
when you have remote which is not '.', and which has branches with the same
names like some of your local branches, and vice versa). mergeLocal would
be unambiguous...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: branch.<name>.merge specifying remote branch name
From: Nicolas Pitre @ 2006-12-23 14:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emirt5$kh3$2@sea.gmane.org>
On Sat, 23 Dec 2006, Jakub Narebski wrote:
> About the discussion about branch.<name>.merge specifying remote branch name
> and relative merits of specifying remote branch name (without need for
> tracking branch), and local branch name (which is supposedly more user
> friendly, and branch name specifies also remote usually)...
>
> Perhaps it is time to resurrect branch.<name>.mergeLocal (or localMerge)
> idea, and both sides would be happy (well, at least when one would code
> it ;-).
Adding more and more options doesn't make it friendlier to use.
Why couldn't both names (local and remote) be accepted by
branch.blah.merge?
Nicolas
^ permalink raw reply
* Re: author/commit counts
From: Johannes Schindelin @ 2006-12-23 14:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Randy Dunlap, git
In-Reply-To: <Pine.LNX.4.64.0612230001590.18171@xanadu.home>
Hi,
On Sat, 23 Dec 2006, Nicolas Pitre wrote:
> git log --author=<blah> | git shortlog -s
Note that the builtin shortlog reuses the fine revision walking machinery:
git shortlog --author=<blah> -n -s
works like a charm.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Johannes Schindelin @ 2006-12-23 14:12 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, junkio
In-Reply-To: <20061223085206.GA2189@cepheus>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1045 bytes --]
Hi,
On Sat, 23 Dec 2006, Uwe Kleine-König wrote:
> Johannes Schindelin wrote:
> > @@ -127,6 +128,15 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> > while (fgets(comment, sizeof(comment), stdin) != NULL)
> > add_buffer(&buffer, &size, "%s", comment);
> >
> > + /* And check the encoding */
> > + buffer[size] = '\0';
> > + if (!strcmp(git_commit_encoding, "utf-8") && !is_utf8(buffer)) {
> Maybe you could be more generous here. E.g.
>
> if ((!strcasecmp(git_commit_encoding, "utf-8") ||
> !strcasecmp(git_commit_encoding, "utf8")) && !is_utf8(buffer))
>
> Junio suggested to make this check if i18n.commitEncoding is empty. I
> didn't check the code to see if this case is included.
The problem is, as I pointed out in another mail, that environment.c sets
the default git_commit_encoding to "utf-8". This is hardwired, and I have
no way to check if that was set by the config or not, other than reparsing
the config myself.
> Gruessle
Hah! You don't use umlauts and ssharp yourself!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: Allow search to be disabled from the config file.
From: Jakub Narebski @ 2006-12-23 13:00 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git
In-Reply-To: <20061223122841.GD11474@localhost>
Robert Fitzsimons wrote:
> Jakub Narebski wrote:
>> I'm not sure if it is worth disabling such not demanding in resources
>> (contrary to pickaxe, blame and to some extent snapshot). Perhaps it would
>> be better to simply paginate search result, like "history" view got
>> paginated?
>
> Yes that makes sense. I'll withdraw this patch and try and come up with
> a new one which can paginate search results.
Besides having removed search, it would follow removing search _form_.
Hmmm... perhaps we should add 'pickaxe' to search form only if it is
enabled?
Something like (warning: this diff is certainly whitespace damaged!):
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5feebaf..585d9fd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1894,7 +1903,8 @@ EOF
$cgi->hidden(-name => "a") . "\n" .
$cgi->hidden(-name => "h") . "\n" .
$cgi->popup_menu(-name => 'st', -default => 'commit',
- -values => ['commit', 'author', 'committer', 'pickaxe
+ -values => ['commit', 'author', 'committer',
+ gitweb_check_feature('pickaxe') ? 'pickaxe' : ()]) .
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
Take a look how it was done for "history" view in commit 8be683520e
"gitweb: Paginate history output"
Although with search you have additional complication with marking match,
and "log" view like rather than "shortlog" like view... so I'm not sure
if it would truly help. On the other hand you can use --skip option you
have introduced...
--
Jakub Narebski
Poland
^ permalink raw reply related
* Re: [PATCH 3/3] gitweb: Allow search to be disabled from the config file.
From: Robert Fitzsimons @ 2006-12-23 12:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emiomr$f4m$1@sea.gmane.org>
> I'm not sure if it is worth disabling such not demanding in resources
> (contrary to pickaxe, blame and to some extent snapshot). Perhaps it would
> be better to simply paginate search result, like "history" view got
> paginated?
Yes that makes sense. I'll withdraw this patch and try and come up with
a new one which can paginate search results.
Robert
^ permalink raw reply
* Re: [RFC] git reflog show
From: Junio C Hamano @ 2006-12-23 10:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061223101956.GD9396@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'm toying with what a 'git reflog show' might look like. I attached
> the prototype code below. Here's the output from the recent part of
> my mmap pack window topic:
>
> $ ./git-reflog show refs/heads/sp/mapwin
> ...clipped for space...
>
The output should look almost the same as "git log" for the part
that represents a series of normal branch activity where commits
are built up one-by-one. I think it would be useful if you can
somehow make parts that are _not_ linear stand out and perhaps
allow omitting a stretch of ordinary single strand of pearls.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Jakub Narebski @ 2006-12-23 10:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqlvrldk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>> Only *if* you store it in that tracking branch. The name the
>> other party gives _do_ matter to you anyway, because you have to
>> _know_ it to fetch. What it does NOT matter is if you use a
>> tracking branch, or if you do, which local tracking branch you
>> use to track it.
>
> Having said that, I think we _could_ do this.
>
> If you (or other people) use branch.*.merge, with its value set
> to remote name _and_ local name, and actually verify that either
> form works without confusion, please report back and I'll apply.
Hmmm... that DWIM is even better than proposed some time ago localmerge
(or mergelocal, I don't remember) config variable.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC] git reflog show
From: Shawn Pearce @ 2006-12-23 10:19 UTC (permalink / raw)
To: Junio C Hamano, git
I'm toying with what a 'git reflog show' might look like. I attached
the prototype code below. Here's the output from the recent part of
my mmap pack window topic:
$ ./git-reflog show refs/heads/sp/mapwin
...clipped for space...
ref sp/mapwin@{10}
commit f6ec09f.. -> 1960ea7..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:46:07 2006 -0500
commit (amend): Support unmapping windows on 'temporary' packfiles.
ref sp/mapwin@{9}
commit 1960ea7.. -> e70352c..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:49:10 2006 -0500
commit: Create pack_report() as a debugging aid.
ref sp/mapwin@{8}
commit e70352c.. -> 161cd2d..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:53:48 2006 -0500
commit (amend): Create pack_report() as a debugging aid.
ref sp/mapwin@{7}
commit 161cd2d.. -> 81e4d26..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:03 2006 -0500
reset --hard
ref sp/mapwin@{6}
commit 81e4d26.. -> e69e59b..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:44 2006 -0500
commit (amend): Fully activate the sliding window pack access.
ref sp/mapwin@{5}
commit e69e59b.. -> 11bedbb..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:51 2006 -0500
am: Load core configuration in git-verify-pack.
ref sp/mapwin@{4}
commit 11bedbb.. -> 88035fd..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:52 2006 -0500
am: Ensure core.packedGitWindowSize cannot be less than 2 pages.
ref sp/mapwin@{3}
commit 88035fd.. -> b3b706e..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:52 2006 -0500
am: Improve error message when packfile mmap fails.
ref sp/mapwin@{2}
commit b3b706e.. -> 62c8beb..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:52 2006 -0500
am: Support unmapping windows on 'temporary' packfiles.
ref sp/mapwin@{1}
commit 62c8beb.. -> 6b43fd0..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 01:58:52 2006 -0500
am: Create pack_report() as a debugging aid.
ref sp/mapwin@{0}
commit 6b43fd0.. -> bbdc8fa..
User: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Dec 23 02:06:23 2006 -0500
commit: Test suite for sliding window mmap implementation.
diff --git a/builtin-reflog.c b/builtin-reflog.c
index d4f7353..7156a2c 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -161,8 +161,173 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
return status;
}
+struct cmd_reflog_list_ref
+{
+ const char *name;
+ unsigned int ent_cnt;
+};
+
+struct cmd_reflog_list_ent
+{
+ struct cmd_reflog_list_ent* next;
+ struct cmd_reflog_list_ref *ref;
+ const char *cmd;
+ char *user;
+ unsigned long timestamp;
+ int tz;
+ unsigned int pos;
+ unsigned char old_sha1[20];
+ unsigned char new_sha1[20];
+};
+
+struct cmd_reflog_list_cb
+{
+ struct cmd_reflog_list_ent* entries;
+ struct cmd_reflog_list_ref* cur_ref;
+ unsigned int ref_cnt;
+ unsigned int ent_cnt;
+};
+
+static int list_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
+ char *data, void *cb_data)
+{
+ struct cmd_reflog_list_cb *cb = cb_data;
+ struct cmd_reflog_list_ent *e;
+ unsigned long timestamp;
+ int tz;
+ char *user_end, *cp, *ep;
+
+ cp = strchr(data, '>');
+ if (!cp || *++cp != ' ')
+ return 0; /* corrupt line? */
+ user_end = cp;
+ timestamp = strtoul(cp, &ep, 10);
+ if (*ep++ != ' ')
+ return 0; /* corrupt line? */
+ tz = strtol(ep, &cp, 10);
+ if (*cp++ != '\t')
+ return 0; /* corrupt line? */
+
+ e = xmalloc(sizeof(*e));
+ e->ref = cb->cur_ref;
+ e->cmd = xstrdup(cp);
+ e->user = xmalloc(user_end - data + 1);
+ strncpy(e->user, data, user_end - data);
+ e->user[user_end - data] = 0;
+ e->timestamp = timestamp;
+ e->tz = tz;
+ e->pos = cb->cur_ref->ent_cnt++;
+ hashcpy(e->old_sha1, osha1);
+ hashcpy(e->new_sha1, nsha1);
+ e->next = cb->entries;
+ cb->entries = e;
+ cb->ent_cnt++;
+ return 0;
+}
+
+static int list_reflog(const char *ref, const unsigned char *sha1,
+ int unused, void *cb_data)
+{
+ struct cmd_reflog_list_cb *cb = cb_data;
+
+ cb->ref_cnt++;
+ cb->cur_ref = xmalloc(sizeof(*cb->cur_ref));
+ cb->cur_ref->name = xstrdup(ref);
+ cb->cur_ref->ent_cnt = 0;
+ for_each_reflog_ent(ref, list_reflog_ent, cb);
+ return 0;
+}
+
+static int list_cmp(const void *_a, const void *_b)
+{
+ const struct cmd_reflog_list_ent *a = *((void**)_a);
+ const struct cmd_reflog_list_ent *b = *((void**)_b);
+ if (a->ref == b->ref)
+ return a->pos < b->pos ? -1 : 1;
+ if (a->timestamp < b->timestamp)
+ return -1;
+ if (a->timestamp == b->timestamp)
+ return 0;
+ return 1;
+}
+
+static void reflog_show(struct cmd_reflog_list_ent *e)
+{
+ const char *ref = e->ref->name;
+ if (!strncmp("refs/heads/", ref, 11))
+ ref += 11;
+ printf("ref %s@{%u}\n", ref, e->ref->ent_cnt - e->pos - 1);
+ printf("commit ");
+ if (is_null_sha1(e->old_sha1))
+ printf("deleted");
+ else
+ printf("%s..", find_unique_abbrev(e->old_sha1, DEFAULT_ABBREV));
+ printf(" -> ");
+ if (is_null_sha1(e->new_sha1))
+ printf("deleted");
+ else
+ printf("%s..", find_unique_abbrev(e->new_sha1, DEFAULT_ABBREV));
+ printf("\n");
+ printf("User: %s\n", e->user);
+ printf("Date: %s\n", show_date(e->timestamp, e->tz, 0));
+ printf("\n");
+ printf(" %s\n", e->cmd);
+}
+
+static const char reflog_show_usage[] =
+"git-reflog show [--all|<refs>...]";
+
+static int cmd_reflog_show(int argc, const char **argv, const char *prefix)
+{
+ struct cmd_reflog_list_cb cb;
+ unsigned char sha1[20];
+ int i, do_all = 0, status = 0;
+ struct cmd_reflog_list_ent **ent_arr;
+ struct cmd_reflog_list_ent *e;
+
+ cb.ref_cnt = 0;
+ cb.ent_cnt = 0;
+ cb.entries = NULL;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!strcmp(arg, "--all"))
+ do_all = 1;
+ else if (arg[0] == '-')
+ usage(reflog_show_usage);
+ else
+ break;
+ }
+ if (do_all)
+ status |= for_each_ref(list_reflog, &cb);
+ while (i < argc) {
+ const char *ref = argv[i++];
+ if (!resolve_ref(ref, sha1, 1, NULL))
+ status |= error("no such ref: %s", ref);
+ else
+ status |= list_reflog(ref, sha1, 0, &cb);
+ }
+ if (!cb.ref_cnt) {
+ const char *ref = "HEAD";
+ if (!resolve_ref(ref, sha1, 1, NULL))
+ status |= error("no such ref: %s", ref);
+ else
+ status |= list_reflog(ref, sha1, 0, &cb);
+ }
+
+ ent_arr = xmalloc(cb.ent_cnt * sizeof(*ent_arr));
+ for (i = 0, e = cb.entries; e; i++, e = e->next)
+ ent_arr[i] = e;
+ qsort(ent_arr, cb.ent_cnt, sizeof(*ent_arr), list_cmp);
+
+ for (i = 0; i < cb.ent_cnt; i++)
+ reflog_show(ent_arr[i]);
+
+ return status;
+}
+
static const char reflog_usage[] =
-"git-reflog (expire | ...)";
+"git-reflog (expire | show | ...)";
int cmd_reflog(int argc, const char **argv, const char *prefix)
{
@@ -170,6 +335,8 @@ int cmd_reflog(int argc, const char **argv, const char *prefix)
usage(reflog_usage);
else if (!strcmp(argv[1], "expire"))
return cmd_reflog_expire(argc - 1, argv + 1, prefix);
+ else if (!strcmp(argv[1], "show"))
+ return cmd_reflog_show(argc - 1, argv + 1, prefix);
else
usage(reflog_usage);
}
^ permalink raw reply related
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-23 9:51 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <7vbqlvuoi4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jeff King <peff@peff.net> writes:
>
>> BTW, is there some explanation why branch.*.merge specifies a _remote_
>> head? The following would make much more sense to me:
>>
>> [branch "master"]
>> remote = origin
>> merge = refs/remotes/origin/master
>
> Only *if* you store it in that tracking branch. The name the
> other party gives _do_ matter to you anyway, because you have to
> _know_ it to fetch. What it does NOT matter is if you use a
> tracking branch, or if you do, which local tracking branch you
> use to track it.
Having said that, I think we _could_ do this.
If you (or other people) use branch.*.merge, with its value set
to remote name _and_ local name, and actually verify that either
form works without confusion, please report back and I'll apply.
My scar is still fresh from the "not having branch.*.merge is an
error" mistake, where the thing stayed on 'next' for the better
part of last week without anybody complaining, and immediately
broken peoples' workflows when it was pushed out to 'master'.
I really do not want to repeat that.
-- >8 --
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index aaef861..b45af5c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -146,8 +146,13 @@ canon_refs_list_for_fetch () {
else
for merge_branch in $merge_branches
do
- [ "$remote" = "$merge_branch" ] &&
- dot_prefix= && break
+ if test "$remote" = "$merge_branch" ||
+ test "z$local" != z &&
+ test "$local" = "$merge_branch"
+ then
+ dot_prefix=
+ break
+ fi
done
fi
case "$remote" in
^ permalink raw reply related
* Re: [PATCH 0/17] Sliding window mmap for packfiles.
From: Shawn Pearce @ 2006-12-23 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkkzrm0w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I have to say i am very much impressed (I've taken a look at
> only the first half up to #11, though). How much has this been
> used in real projects?
None yet. I just finished remerging it onto current git.git code.
> A couple of comments:
>
> [3/17]
>
> I think losing "p->next = NULL" does not matter with the callers
> we have right now, but somehow this part makes me feel uneasy.
That's a bug in that patch. I removed it by mistake. Good catch.
> [5/17]
>
> I think it makes sense to exit(0) for the existing write_or_die
> upon EPIPE because that indicates we are the upstream of the
> pipe and the reading process has exit (i.e. user said 'q' to
> less while we still have more to say).
>
> I suspect the symmetry would not hold for read_or_die; when we
> are reading, EPIPE is not any different from any other errors
> (except for EAGAIN or EINTR which we already take care of in
> xread()) and the net effect is that we could not read what we
> wanted to.
Oh, good point.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/17] Sliding window mmap for packfiles.
From: Junio C Hamano @ 2006-12-23 9:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061223073317.GA9837@spearce.org>
I have to say i am very much impressed (I've taken a look at
only the first half up to #11, though). How much has this been
used in real projects?
A couple of comments:
[3/17]
I think losing "p->next = NULL" does not matter with the callers
we have right now, but somehow this part makes me feel uneasy.
[5/17]
I think it makes sense to exit(0) for the existing write_or_die
upon EPIPE because that indicates we are the upstream of the
pipe and the reading process has exit (i.e. user said 'q' to
less while we still have more to say).
I suspect the symmetry would not hold for read_or_die; when we
are reading, EPIPE is not any different from any other errors
(except for EAGAIN or EINTR which we already take care of in
xread()) and the net effect is that we could not read what we
wanted to.
^ permalink raw reply
* branch.<name>.merge specifying remote branch name
From: Jakub Narebski @ 2006-12-23 9:14 UTC (permalink / raw)
To: git
About the discussion about branch.<name>.merge specifying remote branch name
and relative merits of specifying remote branch name (without need for
tracking branch), and local branch name (which is supposedly more user
friendly, and branch name specifies also remote usually)...
Perhaps it is time to resurrect branch.<name>.mergeLocal (or localMerge)
idea, and both sides would be happy (well, at least when one would code
it ;-).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] Display 'theirs' branch name when possible in merge.
From: Jakub Narebski @ 2006-12-23 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <20061223084447.GB10203@spearce.org>
Shawn O. Pearce wrote:
> Displaying the SHA1 of 'their' branch (the branch being merged into
> the current branch) is not nearly as friendly as just displaying
> the name of that branch, especially if that branch is already local
> to this repository.
>
> git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)'
> for each argument it gets passed, making the actual input name that
> resolved to the commit '%(sha1)' easily available to the invoked
> merge strategy.
>
> git-merge-recursive makes use of these environment variables when
> they are available by using '%(name)' whenever it outputs the commit
> identification rather than '%(sha1)'. This is most obvious in the
> conflict hunks created by xdl_merge:
>
> $ git mege sideb~1
git merge sideb~1
> <<<<<<< HEAD:INSTALL
> Good!
> =======
> Oops.
> >>>>>>> sideb~1:INSTALL
Very nice. Thanks.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] libgit.a: add some UTF-8 handling functions
From: Uwe Kleine-König @ 2006-12-23 8:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612230048350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Hallo Johannes,
Johannes Schindelin wrote:
> @@ -127,6 +128,15 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
> while (fgets(comment, sizeof(comment), stdin) != NULL)
> add_buffer(&buffer, &size, "%s", comment);
>
> + /* And check the encoding */
> + buffer[size] = '\0';
> + if (!strcmp(git_commit_encoding, "utf-8") && !is_utf8(buffer)) {
Maybe you could be more generous here. E.g.
if ((!strcasecmp(git_commit_encoding, "utf-8") ||
!strcasecmp(git_commit_encoding, "utf8")) && !is_utf8(buffer))
Junio suggested to make this check if i18n.commitEncoding is empty. I
didn't check the code to see if this case is included.
Gruessle
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=2+to+the+power+of+12
^ permalink raw reply
* [PATCH 2/2] Display 'theirs' branch name when possible in merge.
From: Shawn O. Pearce @ 2006-12-23 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <6115ec06459724c7c37c355805462cb61715e9c5.1166863413.git.spearce@spearce.org>
Displaying the SHA1 of 'their' branch (the branch being merged into
the current branch) is not nearly as friendly as just displaying
the name of that branch, especially if that branch is already local
to this repository.
git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)'
for each argument it gets passed, making the actual input name that
resolved to the commit '%(sha1)' easily available to the invoked
merge strategy.
git-merge-recursive makes use of these environment variables when
they are available by using '%(name)' whenever it outputs the commit
identification rather than '%(sha1)'. This is most obvious in the
conflict hunks created by xdl_merge:
$ git mege sideb~1
<<<<<<< HEAD:INSTALL
Good!
=======
Oops.
>>>>>>> sideb~1:INSTALL
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-merge.sh | 2 ++
merge-recursive.c | 17 ++++++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index a17aa2c..5c2d03b 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -266,6 +266,8 @@ do
remotehead=$(git-rev-parse --verify "$remote"^0 2>/dev/null) ||
die "$remote - not something we can merge"
remoteheads="${remoteheads}$remotehead "
+ eval GITHEAD_$remotehead='"$remote"'
+ export GITHEAD_$remotehead
done
set x $remoteheads ; shift
diff --git a/merge-recursive.c b/merge-recursive.c
index abebb95..a96821c 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1263,6 +1263,18 @@ static struct commit *get_ref(const char *ref)
return (struct commit *)object;
}
+static char* better_branch_name(const char *branch)
+{
+ static char githead_env[8 + 40 + 1];
+ char* name;
+
+ if (strlen(branch) != 40)
+ return branch;
+ sprintf(githead_env, "GITHEAD_%s", branch);
+ name = getenv(githead_env);
+ return name ? name : branch;
+}
+
int main(int argc, char *argv[])
{
static const char *bases[2];
@@ -1293,11 +1305,14 @@ int main(int argc, char *argv[])
branch1 = argv[++i];
branch2 = argv[++i];
- printf("Merging %s with %s\n", branch1, branch2);
h1 = get_ref(branch1);
h2 = get_ref(branch2);
+ branch1 = better_branch_name(branch1);
+ branch2 = better_branch_name(branch2);
+ printf("Merging %s with %s\n", branch1, branch2);
+
if (bases_count == 1) {
struct commit *ancestor = get_ref(bases[0]);
clean = merge(h1, h2, branch1, branch2, 0, ancestor, &result);
--
1.4.4.3.g87d8
^ permalink raw reply related
* [PATCH 1/2] Use extended SHA1 syntax in merge-recursive conflicts.
From: Shawn O. Pearce @ 2006-12-23 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When we get a line-level conflict in merge-recursive and print out
the two sides in the conflict hunk header and footer we should use
the standard extended SHA1 syntax to specify the specific blob,
as this allows the user to copy and paste the line right into
'git show' to view the complete version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
merge-recursive.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index ae7ae4c..abebb95 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -649,8 +649,8 @@ static struct merge_file_info merge_file(struct diff_filespec *o,
char *name1, *name2;
int merge_status;
- name1 = xstrdup(mkpath("%s/%s", branch1, a->path));
- name2 = xstrdup(mkpath("%s/%s", branch2, b->path));
+ name1 = xstrdup(mkpath("%s:%s", branch1, a->path));
+ name2 = xstrdup(mkpath("%s:%s", branch2, b->path));
fill_mm(o->sha1, &orig);
fill_mm(a->sha1, &src1);
--
1.4.4.3.g87d8
^ permalink raw reply related
* Re: confusion over the new branch and merge config
From: Jakub Narebski @ 2006-12-23 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <20061223051210.GA29814@segfault.peff.net>
Jeff King wrote:
> It also means that even without a remote, the merge option makes sense
> (e.g., if I do repeated merges from one local branch to another). And it
> means that it's _always_ correct for "checkout -b <new> <track>" to set
> branch.<new>.merge to <track>, without having to worry about finding an
> appropriate remote.
Without remote (or rather with remote ".") remote branch names are the same
as tracking branch names :-)
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Use rev-list pattern search options.
From: Jakub Narebski @ 2006-12-23 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <11668449162618-git-send-email-robfitz@273k.net>
Robert Fitzsimons wrote:
> Use rev-list pattern search options instead of hand coded perl.
Very nice. Ack (FWIW).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: Allow search to be disabled from the config file.
From: Jakub Narebski @ 2006-12-23 8:20 UTC (permalink / raw)
To: git
In-Reply-To: <11668449274162-git-send-email-robfitz@273k.net>
Robert Fitzsimons wrote:
[...]
I'm not sure if it is worth disabling such not demanding in resources
(contrary to pickaxe, blame and to some extent snapshot). Perhaps it would
be better to simply paginate search result, like "history" view got
paginated?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] Makefile: add quick-install-doc for installing pre-built manpages
From: Junio C Hamano @ 2006-12-23 7:59 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11668546833727-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> This adds and uses the install-doc-quick.sh file to
> Documentation/, which is usable for people who track either the
> 'html' or 'man' heads in Junio's repository.
Sadly I cannot use this myself ;-).
Two points and a half.
(1) DESTDIR traditionally is always used to denote the virtual
root directory for fake install, typically later to be
copied over elsewhere or tarred up (e.g. "install git.1
$(DESTDIR)/usr/share/man/man1/git.1"); I'd suggest to make
install-doc-quick.sh script take two parameters, the branch
and the destination directory.
(2) "git-clone" makes my html and man branches tracked with
remotes/origin/{html,man} by default; you would want to make
the local tracking branch 'man' you have hardcoded in the
Makefile overridable and make it default to "origin/man".
(2.5) "chmod +x install-doc-quick.sh", even if you say "sh
./..." in your Makefile.
^ 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