Re: [PATCH] gitweb: Paginate history output

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> @@ -1559,6 +1562,7 @@ sub git_history_body {
>>                      next;
>>              }
>>  
>> +            #my $ref = defined $refs ? format_ref_marker($refs, $commit) : '';
>>              my $ref = format_ref_marker($refs, $commit);
>>  
>>              if ($alternate) {
> 
> Do you want to change this or not?  Make up your mind.

I'm not sure. This is an internal function, so $refs should 
be defined. I'm not sure checking here is worth it.

This whole hunk could be removed.

>> +            $paging_nav .= " &sdot; " .
>> +                    $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
>> +                                           file_name=>$file_name, page=>$page-1),
>> +                             -accesskey => "p", -title => "Alt-p"}, "prev");
> 
> This is something you inherited from the original and not your
> fault, but I am not sure if these -title entries are of good
> taste (we have corresponding "Alt-n" for "next").  Something
> more descriptive like "<Alt-p> for 100 newer changes", perhaps?

That would be better.

> Also, "first", "prev" and "next" have always confused me.  Maybe
> "latest", "older" and "newer" are better labels for them?

"first" is only for pagination of "history" action, "shortlog",
"heads" and "tags" have "HEAD" there instead.

> Is 100 a good default?  It feels a bit unbalanced compared to
> the height of the default summary page with descriptions, 16
> shortlog entries, 16 tags and 12 heads.

It's 16 heads (if you have that many), from what I remember 
from source.

The purpose of summary page is to have everything at glance (it means
that it should be contained in one, two pages. The pagination of
output is to not send too much at once.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git