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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.