From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <junkio@cox.net>, git@vger.kernel.org
Subject: Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
Date: Fri, 15 Sep 2006 12:49:35 +0200 [thread overview]
Message-ID: <200609151249.35872.jnareb@gmail.com> (raw)
In-Reply-To: <7v4pv91wqk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Now, once we start doing this, it may make sense to rethink how
> this function and git_get_references functions are used. I
> think
>
> git grep -n -e '^sub ' \
> -e git_get_references \
> -e git_get_refs_list gitweb/gitweb.perl
>
> would be instructive how wasteful the current code is.
>
> get_refs_list is called _TWICE_ in git_summary and worse yet
> very late in the function, after calling git_get_references that
> could already have done what the function does (by the way,
> git_get_references already knows how to use peek-remote output
> but for some reason it uses ls-remote -- I think you can safely
> rewrite it to use peek-remote). So you end up doing peek-remote
> three times to draw the summary page.
>
> git_get_references are called from almost everywhere that shows
> the list of commits, which is understandable because we would
> want to see those markers in the list.
>
> I very much suspect that you can use git_get_refs_list to return
> a hash and a sorted list at the same time from the same input
> and make git_summary to do with just a single call to it, and
> get rid of git_get_references with a little bit of restructuring
> of the caller.
We can easily collapse two calls for git_get_refs_list in gi_summary,
one for tags and one for heads into one call plus some filtering.
Changing git_get_refs_list to do also the job of git_get_references
means that in git_tags and git_heads we do extra the job of
git_get_references. Neither git_tags, nor git_heads use references and
refs marker; using the heads references in git_heads and tags
references in git_tags is repeating the same information twice,
cluttering the output. Unless we want to add yet another subroutine...
But as call to git-peek-remote is what takes most time, we can waste
some time processing references which we would not use for the sake of
clarity. Well, we can get rid of git_get_references too, if we don't
mind slight decrease in performance.
We would then use:
git_summary:
my ($refs, $reflist) = git_get_refs_list();
my @taglist = map { s!^tags/!! } grep { m!^tags/! } @$reflist;
my @headlist = map { s!^heads/!! } grep { m!^heads/! } @$reflist;
git_heads, git_tags:
my (undef, $taglist) = git_get_refs_list("tags");
my (undef, $headlist) = git_get_refs_list("heads");
everywhere else
my ($refs, undef) = git_get_refs_list($type);
--
Jakub Narebski
Poland
prev parent reply other threads:[~2006-09-15 10:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 21:27 [PATCH] gitweb: Do not parse refs by hand, use git-peek-remote instead Jakub Narebski
2006-09-14 23:09 ` Junio C Hamano
2006-09-15 1:43 ` [PATCH (take 2)] " Jakub Narebski
2006-09-15 6:15 ` Junio C Hamano
2006-09-15 7:14 ` Jakub Narebski
2006-09-15 7:48 ` Junio C Hamano
2006-09-15 8:43 ` Jakub Narebski
2006-09-15 9:05 ` Junio C Hamano
2006-09-15 10:49 ` Jakub Narebski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200609151249.35872.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).