Re: [RFC/PATCH] gitweb: Paginate project list

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 13 May 2008, Lars Hjemli wrote:
> On Tue, May 13, 2008 at 7:04 PM, Jakub Narebski <jnareb@gmail.com>
> wrote: 
>> On Tue, 13 May 2008, Lars Hjemli wrote:
>>>
>>> [...] (cgit never touches the repos to generate
>>> the project list/search).
[...]
>>  Second, gitweb's projects list page contains "Last Changed" column,
>>  and you _*have*_ to hit repositories for this data
> 
> No you don't. One alternative is to use the post-update hook in each
> repo to update a separate file with info about last-changed-time.

Well, adding setting / caching last-changed data using post-update hook
was one of my early patches to gitweb, but it got shot down. Mainly 
because the fact that it doesn't work with gitweb as "usergit" service,
as you won't be able to install hooks into other users repositories, 
like in the kernel.org case (it should/would work for repo.or.cz etc.).
Another issue is if you publish via web interface non-bare repo; then
update is not the only way data arrives at repository (yes, I know that
post-commit would solve this).

> Another (less accurate) alternative is to stat one or more of
> packed-refs and refs/heads/*; 

And now, in the times of detached HEAD, also HEAD.

BTW. how this work with hierarchical branch names?

>                               cgit uses both of these alternatives to 
> avoid hitting the repo (i.e. object-db) when the project list/search
> page is generated.

First is implicit caching of data, made easier because in this case you
can invalidate cache when it becomes invalid.  Second doesn't hit the 
object-db, but it hits I/O (perhaps very slightly); and the second 
solution is what we can pursue for gitweb in addition to caching data.

Additional complication is that currently there is no place for 
timestamp in project_index format (backward compatibility, unnamed 
tuple not good design to storing structured/tabular data).

-- 
Jakub Narebski
Poland