Re: [PATCH] gitweb: Paginate commit/author/committer search output

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 23, 2006, 22:43 UTC
Message-ID: <200612232343.20815.jnareb@gmail.com>
In-Reply-To: <20061223145712.GE11474@localhost>

Robert Fitzsimons wrote:

Show 13 quoted lines

> Paginate commit/author/committer search output to only show 100 commits
> at a time, added appropriate nav links.
> 
> Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
> --- 
> 
>> Although with search you have additional complication with marking match,
>> and "log" view like rather than "shortlog" like view... so I'm not sure
>> if it would truly help. On the other hand you can use --skip option you
>> have introduced...
> 
> I used the slower non--skip workflow for the moment, so at least there
> is no need to upgrade the core git commands.

First, git has tradition of introducing options (first) meant for gitweb, and immediately making use of them. Examples: --git-dir=<path> option to git wrapper because in mod_perl doesn't pass environmental variables to subprocesses so setting $ENV{'GIT_DIR'} in gitweb wouldn't work; --full-history option to git-rev-list for "history" view, because using path limit instead of piping to git-diff-tree and using path limit of git-diff-tree changed returned revisions, git-for-each-ref introduced for better gitweb performance in "summary" view... So you wouldn't do something unusual. And it is fairly easy to compile and install additional, newest version of git.

Second, without --skip you have ugly tradeoff if you want to paginate (search result, but not only that): either get pages*page-size revisions and call parse_commit which in turn usually calls git-rev-list page-size times; or get full info pages*page-size and skip (pages - 1)*page-size bits of output.

And finally, --skip with your abandoned for now parsing revisions not one by one, but by a bunch using one git command call would help performance not only of non-pickaxe search, but also history view, and log and shortlog views.

[...]

> +sub git_search_grep_body {

I'm not sure if it wouldn't be better to try to reuse git_log machinery, just adding marking match, and removing everything but the immediate context of match, to format_log_line_html... Just a thought...

-- 
Jakub Narebski
Poland