git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).