git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead

From
Jakub Narebski <jnareb@gmail.com>
Date
Sep 15, 2006, 10:49 UTC
Message-ID
<200609151249.35872.jnareb@gmail.com>
In-Reply-To
<7v4pv91wqk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 27 quoted lines
> 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
Previous: Junio C Hamano
Message 9 of 9 in “gitweb: Do not parse refs by hand, use git-peek-remote instead”
  1. gitweb: Do not parse refs by hand, use git-peek-remote insteadJakub Narebski, Sep 14, 2006
  2. Junio C HamanoSep 14, 2006
  3. gitweb: Do not parse refs by hand, use git-peek-remote insteadJakub Narebski, Sep 15, 2006
  4. Junio C HamanoSep 15, 2006
  5. Jakub NarebskiSep 15, 2006
  6. Junio C HamanoSep 15, 2006
  7. Jakub NarebskiSep 15, 2006
  8. Junio C HamanoSep 15, 2006
  9. Jakub NarebskiSep 15, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.