Re: [PATCH/RFC] gitweb: Great subroutines renaming

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 9, 2006, 10:26 UTC
Message-ID: <ebcd8r$bi7$1@sea.gmane.org>
In-Reply-To: <7vejvsyum8.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 12 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Matthias Lederhofer has noticed that parsing all the tags in "summary" and
>> "tags" views, while we use only epoch/timestamp information to sort them
>> and discard most of parsed input, is bottleneck due to the fact that
>> usually number of tags is linear with history (version tags) and the fact
>> that for each tag is one invocation of git (one fork, two execs).
> 
> Maybe we would want to expose for_each_ref somehow to the
> command level then.  Looking at how "git branch" without any
> argument lists the branches, and how "git tag -l" lists the
> tags, it appears that we could benefit from such a command [*1*].

> -- >8 -- [*1*] -- >8 --
> [PATCH] git-show-refs
> 
> Implementation is left as an exercise ;-)

[...]

> +SYNOPSIS
> +--------
> +'git-show-refs' [--count=<max>] [--sort=<sortkeys>] [--format=<format>] [<pattern>]

It would be useful for application in gitweb to have [-l|--count-lines] option which would print number of lines (excluding the one with number of lines) before any output. It could be used to know before reading all the output how many lines would be, and if there is something more than (for --count=<max>) <max> lines.

It is needed in gitweb to create pagination/paging navigation bar. Currently it is done by reading all the output into array, and checking length of this array.

While at it, --skip=<count> would also be nice, although not that necessary.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git