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

From: Junio C Hamano <junkio@cox.net>
Date: Sep 15, 2006, 06:15 UTC
Message-ID: <7v4pv91wqk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200609150343.28334.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 6 quoted lines

> This is in response to Linus work on packed refs. Additionally it
> makes gitweb work with symrefs, too.
>
> Do not parse refs by hand, using File::Find and reading individual
> heads to get hash of reference, but use git-peek-remote output
> instead.

Looks nicer.  Will apply.

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.

Hmm?